High
CVE-2024-6387
High
(3 users assessed)
Very Low
(3 users assessed)Unknown
Unknown
Unknown
Description
A security regression (CVE-2006-5051) was discovered in OpenSSH’s server (sshd). There is a race condition which can lead to 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.
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
- Red Hat
Products
- Red Hat Enterprise Linux 9,
- Red Hat Enterprise Linux 6,
- Red Hat Enterprise Linux 7,
- Red Hat Enterprise Linux 8,
- Red Hat OpenShift Container Platform 4
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.