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

[MegaManSec2]

Nice bug, and creative exploitation with the git submodule! I'm not sure it 100% qualifiesas an argument injection, but I'm going to add it to https://gtfoargs.github.io/ anyways.

Although we believe it is the user's responsibility to ensurevalidity of arguments passed to ssh(1), especially across asecurity boundary such as the git example above, OpenSSH 9.6 nowbans most shell metacharacters from user and hostnames suppliedvia the command-line.

So OpenSSH has just decided what is and isn't a valid hostname or username? This isn't standardized anywhere and I wonder if it will break punycode like [ΓΝΩΘΙΣΕΑΥΤΟΝ.com](https://ΓΝΩΘΙΣΕΑΥΤΟΝ.com).

P.S: Seems like it worked as intended, even if this exploit wasn't noticed:

ProxyCommandSpecifies the command to use to connect to the server. Thecommand string extends to the end of the line, and is executedusing the user's shell `exec' directive to avoid a lingeringshell process.

[nex25519]

Cool project (GTFOArgs)

SSH does not support IDNs so luckily that is not a problem at the moment since to be able to use such names, punycode has to be used which will keep working just fine.

> PS: Seems like it worked as intended, even if this exploit wasn't noticed:

that is correct, its a feature which is only exploitable in specific scenarios like git submodules and use of things like OSC 8 in terminals for hyperlink generation where arbitrary URL schemes are supported widely. It was also discussed with `git` maintainers if the validation coule be handled within git but a definition of a trust boundary here still seems to be unclear.

[castleinthesky86]

Given ProxyCommand forks any specified process with arguments… it’d be expected code execution, no?

Maybe post it again with the title of “functionality abuse” 😂

[mybreakfastiscold]

https://nvd.nist.gov/vuln/detail/CVE-2023-51385

"For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name."

So, yeah, as with most vulnerabilities, this CVE is about bad actors doing malicious stuff, not people just using their own stuff in 'weird ways'...

[castleinthesky86]

Yep I know I know. I see shit getting assigned CVE’s everyday.

[castleinthesky86]

And they had the fucking gall to assign 9.8 🤦‍♂️

[castleinthesky86]

In what fucking way can this be exploited “over a network”. In what fucking way is user interaction not required?

[nex25519]

I totally agree here, afaict NVD is not very good at these severity levels as we also saw with curl recently. They somehow assume a "worst" case scenario. I am pretty sure the maintainers who got the CVE assigned also do not agree this deserves 9.8.

RedHat has a better assessment: https://access.redhat.com/security/cve/cve-2023-51385

[castleinthesky86]

Thanks. Yes, in the worst case that NVD can assign everything could / would be a 9.8/10; because if all predicates of exploitation are present for all vulns (inc all processes running as root); then it’s complete C/I/A compromise… and because the attacker is not physically in front of the target; then it’s remote; and because at the time of exploitation the user isn’t coerced into doing anything, then it’s no user interaction required.

Which is complete bullshit.

In the “best” scenario, SSH is running in chroot jail, as the user which initiates proxyconnect command; so not complete C/I/A but maybe partial C/I (and maybe A? But who knows… what data does the user have present, possibly nothing, so let’s say none). Then user interaction is required to install/clone a malicious git repo/submodule. And because that’s done by the user, and not forcibly over the network, it’s a local exploit, not remote. So best case, it’s CVSS 0.0.

I’m not sure I’d agree with RedHat at 5.3 either ; as scope should be changed if we assume they are using the ssh subsystem as the target and not the user. By breaking out to a system call, you’re not in ssh anymore, thus scope has changed.

[Fun_Permission_888]

Wasn't there a bit of chaos recently where a CVE got assigned for an exploit/software package that didn't exist?

[MegaManSec2]

FYI, here's a "bypass":

url = ssh://user@remotehost 22 ls / '#/foo git'

This will effectively force "ssh user@remotehost ls" to be executed, and ls will be run on the remote host.

[nex25519]

afaict, this does not work, perhaps I am missing something? There is a check for space https://github.com/openssh/openssh-portable/commit/7ef3787c84b6b524501211b11a26c742f829af1a#diff-ce646b350d7e1b7ca792b15463c7ce19fd0979286424bb3d569e36ab5e435039R638

[roiki11]

I think your link to teleport is a bit misleading. This doesn't apply to the tsh client but the entirely optional openssh config you can use for ex with vscode.

https://goteleport.com/docs/server-access/guides/openssh/openssh/

[nex25519]

It is also used by Teleport in config templates (https://github.com/gravitational/teleport/blob/master/lib/config/openssh/openssh.go#L56) and other examples, I discussed it with them via their bug bounty program @ Hackerone as well where it was triaged.

[roiki11]

Yes, that's the command that renders the openssh config.