Hacker News Reader

Comment by cwillu | Hacker News Reader

From the OpenSSH update:

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

View on HN

I guess the real issue is that ProxyCommand is evaluated by a shell, but the substitutions is done textually by ssh rather than by the shell, i.e., by providing the hostname via a environment variable.

It does not seem as critical for public SSH servers but does seem pretty bad for ssh clients using ProxyCommand in their configurations.

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

Yeah, I missed the cutoff to edit my original comment. It's quite the footgun due to the combination of a forced involvement of a shell and a built-in naive value substitution.

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.

> but honestly it's not far off that level of “well, duh”

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

The OpenSSH fix isn't a fix though, it depends on ssh knowing what badness needs to be filtered out, but the shell is set by the user.

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)

OP here. Another interesting attack vector I have been working on is OSC 8 for hyperlink support in terminals. Mostly they allow arbitrary url schemes including "ssh://" without any prompt or user interaction to consent to open an external tool like ssh client in this case.

A good discussion on this: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3c...

Reply on news.ycombinator.com