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@mindrot.org
Reporter: sshbug24.10.hackie@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@myserver echo a "b c" d
-vvv: debug1: Sending command: echo aaa b c d
< a b c d
> ssh me@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@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@myserver echo a "b c" d
-vvv: Sending command: echo aaa 'b c' d
< a b c d
(space is preserved)
> ssh me@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@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@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
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@mindrot.org
Reporter: sshbug24.10.hackie@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@myserver echo a "b c" d
-vvv: debug1: Sending command: echo aaa b c d
< a b c d
> ssh me@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@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@myserver echo a "b c" d
-vvv: Sending command: echo aaa 'b c' d
< a b c d
(space is preserved)
> ssh me@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@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@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs