“Although we believe it is the user's responsibility to ensure validity of arguments passed to ssh(1), especially across a security boundary such as the git example above, OpenSSH 9.6 now bans most shell metacharacters from user and hostnames supplied via the command-line. This countermeasure is not guaranteed to be effective in all situations, as it is infeasible for ssh(1) to universally filter shell metacharacters potentially relevant to user-supplied commands.” --https://www.openssh.com/txt/release-9.6
It's not quite a “root can do things as root” CVE, but honestly it's not far off that level of “well, duh”. You can't inject untrusted input (a hostname in this case) into a general purpose command stream (i.e., the arguments to bash -c or an exec call), and not expect to have trouble.
I had this in my config for proxying over tor and seems like it is vulnerable.
```
ProxyCommand connect -5 -S localhost:9050 `tor-resolve %h` %p
```
https://swrdfish.github.io/2015/01/08/ssh-and-git-through-to...
If ssh made the parameters available as environment variables, you could do “ProxyCommand connect -5 -S localhost:9050 "$(tor-resolve "$HOST")" "$PORT"”, which wouldn't be vulnerable to this as long as connect and tor-resolve don't themselves have similar issues with their parameter handling: $HOST could still expand to other switches on tor-resolve, but it couldn't expand to extra commands or quotemarks that bash (or whatever) would process.
Which still isn't great, but at least it would be possible to get it right with sufficient care and attention.
I think the real problem is that other apps do use ssh and malicious actors can inject untrusted input without the user's consent.
The git POC is one example, and while I do think that git also needs to be updated, fixing the problem on the ssh side is also a good idea
It needs to be changed to pass data in a way that doesn't require escaping to reference, such as an environment variable: "$HOST" would then be expanded by the shell, and all the usual rules for safely using environment variables would apply, because ssh wouldn't be the thing performing the variable expansion like it is now.
(For most purposes, my original take in the top level was wrong, but it's too late to edit it now)
A good discussion on this: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3c...
Host github.com
ProxyCommand connect -H localhost:54321 %h %plocalhost:54321 is a SOCK5 proxy, which forwards the traffic through TLS to my VPS server.