Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

vin01.github.io

Post reply on HN
Print view View original

1–10 of 16 posts

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#2

Post by cwillu »

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.

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#3

Post by cwillu »

cwillu wrote: post #2

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 fi…

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.

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#4

Post by Funnnny »

cwillu wrote: post #2

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 fi…

> 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

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#5

Post by cwillu »

Funnnny wrote: post #4
cwillu wrote: post #2

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 fi…

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

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#8

Post by leftcenterright »

bdd8f1df777b wrote: post #6

Wow, this is a security vulnerability potentially affecting me. I'm using ProxyCommand because GitHub is randomly blocked by the China GFW.

This is interesting insight, would you care to share some parts of your ssh config indicating how you use ssh over a proxy here, most likely through a VPN?

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#9

Post by leftcenterright »

cwillu wrote: post #2

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 fi…

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

Re: SSH ProxyCommand == unexpected code execution (CVE-2023-51385)

#10

Post by cwillu »

leftcenterright wrote: post #9
cwillu wrote: post #2

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 fi…

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.

Post reply on HN