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-b...@mindrot.org Reporter: sshbug24.10.hac...@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