OpenSSH 9.3p2 released

For undeadly readers who are curious about the advisory, here is the fascinating Qualys write-up: https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt

As OpenBSD developer Ted Unangst remarked: "DOP: dlopen oriented programming". ;)

Does anybody know, why is mostly everything concerning ability to have a private key safely trapped in a crypto device in such a unfortunate state?

Someone asked for a simpler explanation of the remote exploit fixed in this release, so I wrote this up and thought I'd post it here too, in case the Qualys text feels a bit too long:

----------------
If you run ssh -A combined with ssh-agent so that you can "bring along" your auth when you jump via one box to another, the remote box can/could ask the middle box for specific kinds of auth to be used, and the ssh -A setup will bring this request back to your starting host for it to make a signature or whatever is required to prove it is you.

The first odd part they found was that the middle-box can name the auth method it wants to use, in such a way that your originating host will load named libs from /usr/lib (and /usr/local/lib) in order to attempt to do the PCKS#11 auth dance.

If your starting host has a bunch of poorly written libs, this can be exploited. In their example, they knew they needed to get the stack writeable, and some kind of abort/signal handler to point there, a lib that crashes on launch (more or less) and so on.

By fuzzing around a linux box with tons and tons of libs, they found a set of libs that each made one of the requirements just by running their init routines. So the middle box (which the attacker needs to control) says for example:
"I think you should auth via jpeg" and your box loads /usr/lib/libjpeg.so, runs the init code for this lib, ssh-agent does not find auth-related symbols and unloads it for security, running its exit code (which has no undoing effect).

Most/many of the libs they used would cause security worsening effects at init which they did not undo at exit, so just loading them one at a time would apply those effects to the program opening them (ssh-agent) which sufficed to set up the env to allow a crash bug to make it return into the now writeable stack, and then the exploit is run from there.

So, to be vulnerable, you need to run ssh-agent, then "ssh -A" into a box controlled by your attacker, and lastly have a known bunch of libs with these properties installed.

Using -J instead of -A will help, and I am somewhat certain that not-using-linux also does, at least for now.