[Bug 3677] New: Proper excaping for ssh remote command line

[bugzilla-daemon at mindrot.org]

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.