openssh bugs - Oct 2022 - [Bug 3486] New: SSH_ORIGINAL_COMMAND does not contan the original command anymore

https://bugzilla.mindrot.org/show_bug.cgi?id=3486

            Bug ID: 3486
           Summary: SSH_ORIGINAL_COMMAND does not contan the original
                    command anymore
           Product: Portable OpenSSH
           Version: 9.0p1
          Hardware: Other
                OS: Cygwin on NT/2k/Win7-11
            Status: NEW
          Severity: security
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: martin.rupp at nefkom.net

For some time ago I used the the possiblity to see the original command
in the variable SSH_ORIGINAL_COMMAND. It worked very good.

E.g. if a user used a scp command to copy a file to target directory I
was able to see that the user has invoked the scp command I was able to
see the target directory in the variable SSH_ORIGNAL_COMMAND.

To evaluate the content of the SSH_ORIGINAL_COMMAND I have created a
script to check if the user executes really this scp command and it was
also possible to check if the target directory is the right one.

In newer versions of sshd the variable contains only
"/usr/sbin/sftp-server" or "internal-sftp", dependent on the
assignment
of the "Subsystem"  definition in the /etc/sshd_config-file.

It was really a good method to ensure that user use really the scp
command and doesn't use other targets (e.g. .ssh/authorized_key).

How can I get back the behaviour of sshd, that SSH_ORIGNAL_COMMAND
contains really the orginal command (with some changes, because the
variable contained in the past "scp -t
<target-folder/target-file>"
instead of the really command. but this was sufficient to see the
important things like command and target folder.

I am able to disable all other security concerns via no-pty etc.

But I cannot ensure that the user really use only the foreseen folder.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3486

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djm at mindrot.org
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
SSH_ORIGNAL_COMMAND is accurate: for the last few releases scp(1) has
used the sftp protocol for file transfers, and the sftp protocol
doesn't operate via the command-line as the scp/rcp protocol did.

So there's no way to get the paths back in SSH_ORIGINAL_COMMAND for
newer scp clients. 

The only controls over file visibility that are available for
sftp-server are sshd_config ChrootDirectory and file system
permissions.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3486

--- Comment #2 from Martin Rupp <martin.rupp at nefkom.net> ---
I cannot use the ChrootDirectory. I get an error.
I think the issue is Cygwin (no root user) and also the constraint that
all components of the Chroot path must be owned by UID 0 and GID 0 and
only be writeable by root.

Target path is /cygdrive/d/<subfolder1>/<subfolder2>

Also Chroot is not very secure in Cygwin.

It was so simple to filter the target path in SSH_ORIGINAL_COMMAND. I
used only a simple script which I have assigned to the command part in
the authorized keys.

I have also a very bad issue with sshd in Cygwin. I can copy files to
folders where the transfer user, used in the scp command, has no write
permission.

sshd is running under SYSTEM (= Local System).

If I use it without the filter of the correct information in
SSH_ORIGINAL_COMMAND, users can copy files to all location on the
Windows server. It is very unsecure and it is unuseable for me.

I need a solution as soon as possible.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3486

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
OpenSSH 9.3 has been released. Close resolved bugs

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.