openssh bugs - Apr 2024 - [Bug 3677] New: Proper excaping for ssh remote command line

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

            Bug ID: 3677
           Summary: Proper excaping for ssh remote command line
           Product: Portable OpenSSH
           Version: 8.9p1
          Hardware: amd64
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: sshbug24.10.hackie at recursor.net

If the remote command line contains arguments, it seems that these
arguments are merged to a single string command.

ACTUAL SITUATION:
> ssh me at myserver echo a "b  c" d
-vvv: debug1: Sending command: echo aaa b  c d
< a b c d
> ssh me at myserver echo a 'b " c' d
-vvv: debug1: Sending command: echo aaa b " c d
< bash: -c: line 1: unexpected EOF while looking for matching `"'
< bash: -c: line 2: syntax error: unexpected end of file
> ssh me at myserver echo a "b ' c" d
-vvv: debug1: Sending command: echo aaa b ' c d
< bash: -c: line 1: unexpected EOF while looking for matching `''
< bash: -c: line 2: syntax error: unexpected end of file

EXPECTED:
> ssh me at myserver echo a "b  c" d
-vvv: Sending command: echo aaa 'b  c' d
< a b  c d
(space is preserved)
> ssh me at myserver echo a 'b " c' d
-vvv:     Sending command: echo aaa 'b " c' d
-vvv: or: Sending command: echo aaa "b \" c" d
< a b " c d
(any character is preserved, no character/combination can break out of
the argument)
> ssh me at myserver echo a "b ' c" d
-vvv:     Sending command: echo aaa 'b '"'"' c' d
-vvv: or: Sending command: echo aaa "b ' c" d
< a b ' c d
(same)

ADVANCED EXAMPLE:
> $ a="this ; echo or that"
> $ ssh me at myserver echo the string is "$a"
< the string is this
< or that

expected:

< the string is this ; echo or that

imagine if the string is:
> $ aDONTTRY="this ; rm -rf /"
here we are also entering the topic of possible injection of malicious
code

DETAILS:

In today's times, users just expect that _all_ commands can correctly
handle arguments, at least in pure linux/unix environments.

I think it's easy to implement an escaping engine in the ssh client
which can handle even the most complex strings and transform them into
a single-string command with correct escaping.

The harder part is probably the transition: some users might have
written workarounds around this and will fail if this changes. Maybe we
need an option to enable/disable the new behaviour, but I would
recommend it as a default, for security reasons.

See also this post at stackexchange:
https://unix.stackexchange.com/questions/397400/does-ssh-really-fail-correctly-escaping-remote-commands?noredirect=1#comment1478787_397400

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #1 from Darren Tucker <dtucker at dtucker.net> ---
(In reply to Daniel from comment #0)
> ssh me at myserver echo a 'b " c' d
If you don't need stdin, you can work around some of your examples by
specifying the shell you want and feeding the command via a here doc:

$ ssh localhost /bin/sh <<EOD
echo a "b ' c" d
EOD

a b ' c d

[...]
> I think it's easy to implement an escaping engine in the ssh client
It's not.  It's probably not even possible.  Even if it was, modifying
the sent command behind the user's back is dubious.

In the ssh spec, the "exec" channel request has a single command
string: https://datatracker.ietf.org/doc/html/rfc4254#section-6.5

and while you might be able to do it for *a* shell, you don't know what
the user's shell is at the other end.  Does your escaping work with
zsh?  csh?  tcsh?  fish?  You don't even know if the other end is
attached to a vaguely POSIX-like environment.  Does your escaping work
with Windows?  VMS?  z/OS?  NonStop?  Cisco routers?  A random
appliance?

To do what you're describing in a supportable way, it'd probably need
to be an "execv" protocol extension.  This has been discussed in the
past (eg https://marc.info/?l=openssh-unix-dev&m=110195952412587&w=2)
but it also has many potential problems: how do you handle fallback
when the extension is not supported?  Do you require a full path to the
executable?  if not, where do you get $PATH since the shell usually
sets it? and other environment variables?  These limitations (and
probably others) limit the potential utility of this approach too.

-- 
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.