OpenBSD Journal
Contributed by grey on from the It's Wednesday, but you should still patch this now. dept.
"We've just made an OpenSSH release to fix a remotely exploitable RCE vulnerability in ssh-agent's PKCS#11 support (CVE-2023-38408). Details at https://openssh.com/releasenotes.html#9.3p2
Thanks to the Qualys Security Advisory Team for finding and reporting this bug."
This appears to impact every version of OpenSSH's ssh-agent from 5.5 onwards.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By grey (grey) on http://www.artkiver.com
As OpenBSD developer Ted Unangst remarked: "DOP: dlopen oriented programming". ;)
By d.c. (d.c.) on
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?
By Janne Johansson (jj) jj@stacken.kth.se on http://www.inet6.se
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.