High
CVE-2024-6387
CVE-2024-6387
Description
A security regression (CVE-2006-5051) was discovered in OpenSSH’s server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period.
Add Assessment
Technical Analysis
TL;DR: Neat! Doesn’t sound like something that’s going to be easily exploited or automated in pretty much any scenario, so I have little initial concern about widespread exploitation, or even exploitation at all. I’d expect a long tail of follow-on patches as various distros/products patch it out. Patch, sure, but no need for panic as far as we can tell.
As usual, happy to be proven wrong, but from the (very good!) Qualys technical write-up, this is a memory corruption bug where an adversary would have to win a race condition to exploit it successfully. The Qualys write-up even explicitly notes that “In our experiments, it takes ~10,000 tries on average to win this race condition; i.e., with 10 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime), it takes ~1-2 days on average to obtain a remote root shell.”
Technical Analysis
Doesn’t lend itself to an attackers needs. Takes a very long time to exploit, only works on a specific architecture (32bit), easily detected/blocked as malicious and requires access to a protocol (ssh) that is commonly hardened with access control lists.
Quick follow up – I presume if port 22 is not public-facing then the criticality is much lower.
Hey, quick follow up as well – I think CVE-2024-6387 does affect 64-bit systems. The vulnerability, which is a signal handler race condition in OpenSSH, impacts both 32-bit and 64-bit architectures on glibc-based Linux distributions. While the proof-of-concept exploit was initially developed for 32-bit (x86) systems, it has been indicated that 64-bit (amd64) systems are theoretically vulnerable as well. Exploiting CVE-2024-6387 on 64-bit systems is less likely due to robust Address Space Layout Randomization (ASLR) and the increased complexity of memory allocation, which make precise timing and memory manipulation more challenging.
@themrhagan Thanks! I haven’t yet heard of (or seen) a working PoC for this, so regardless, I’m still not super concerned, but that is good context!
@ccondon-r7 yea, its a very low likelihood of it triggering but it is still theoretically possible so I wanted to call it out. Again though, very low likelihood with the compounded effects of the race condition triggering with ASLR.
@themrhagan definitely, will pass that info on to the team as well
Technical Analysis
While this vulnerability is interesting, and it certainly has the potential for immense damage and harm, the reality is far more nuanced. The difficulty in exploiting this vulnerability is significant, and will likely have to generate a lot of noise from the attacker. It takes a matter of hours (the quickest to date has been around 4 hours under lab conditions) to successfully exploit, which a lot of traffic and noise that for the most part will not go unnoticed if an organisation has the appropriate monitoring in place.
In addition, this is a not vulnerable on numerous LTS base Operating Systems such as:
- RHEL (and thus CentOS) 6, 7, 8 (https://access.redhat.com/security/cve/CVE-2024-6387)
- Ubuntu bionic, focal, trusty (https://access.redhat.com/security/cve/CVE-2024-6387)
interesting… your comments and your attacker value ratings don’t seem to line up.
@cschie822_comcast it depends if one means the attacker value in case of successful exploitation (which is very high here) or if it is the global attacker value taking every other metrics into account such as the very difficult exploitability (the value is very low). So it depends if it is contextualized or not.
What @noraj said! If successfully exploited, it almost likely gives root access to the system which is about as good as it gets for an attacker. But the effort required to do so is significant, making the chances of successful exploitation very low. So from a risk perspective (risk = impact * likelihood), where the impact (attacker value) is incredibly high, but the likelihood (exploitability) is very low, putting it at about medium risk.
CVSS V3 Severity and Metrics
General Information
Vendors
- amazon,
- canonical,
- debian,
- freebsd,
- netapp,
- netbsd,
- openbsd,
- redhat,
- suse
Products
- debian linux 12.0,
- e-series santricity os controller,
- enterprise linux 9.0,
- enterprise linux eus 9.4,
- enterprise linux for arm 64 9.0 aarch64,
- enterprise linux for arm 64 eus 9.4 aarch64,
- enterprise linux for ibm z systems 9.0 s390x,
- enterprise linux for ibm z systems eus 9.4 s390x,
- enterprise linux for power little endian 9.0 ppc64le,
- enterprise linux for power little endian eus 9.4 ppc64le,
- enterprise linux server aus 9.4,
- freebsd 13.2,
- freebsd 13.3,
- freebsd 14.0,
- freebsd 14.1,
- linux 2023 -,
- linux enterprise micro 6.0,
- netbsd,
- ontap select deploy administration utility -,
- ontap tools 9,
- openshift container platform 4.0,
- openssh,
- openssh 4.4,
- openssh 8.5,
- ubuntu linux 22.04,
- ubuntu linux 22.10,
- ubuntu linux 23.04
References
Advisory
Exploit
A PoC added here by the AKB Worker must have at least 2 GitHub stars.
Miscellaneous
Exactly, yet another vulnerability that is marketized as critical and requires urgent attention while it will probably never be exploited outside very niche cases.
But as for XZ backdoor, no one now how it will evolve so it’s still better to patch.
Check it out, Santander’s team investigation, analysed on fake SSH exploits POC.
https://santandersecurityresearch.github.io/blog/sshing_the_masses
@s4mb4sh whoa, that blog is awesome.