The Qualys Threat Research Unit has discovered a new “high” severity signal handler race condition vulnerability in OpenSSH’s server software (sshd). According to the research, this vulnerability has the potential to allow remote unauthenticated code execution (RCE) for glibc-based Linux systems. This CVE has the potential to affect 14 million servers. Exploitation of this bug, at the time of publication, requires a lot of effort; it would take an attacker between 6-8 hours against a 32-bit Linux OS in a lab environment to trigger the RCE. It is likely, however, that given the opportunity, attackers will find ways to exploit systems that have not been patched. It should be noted that, as of yet, no active exploits have been seen in the wild.
Assigned CVE-2024-6387, security teams should immediately identify if their systems are susceptible to the condition. Notably, versions 8.5p1 to 9.7p1 (inclusive), as well as versions prior to 4.4p1, are vulnerable to the race condition bug.
Vulnerable versions:
- Open SSH version earlier than 4.4p1, unless they are patched for CVE-2006-5051 and CVE-2008-4109
- OpenSSH versions 8.5p1 up to but not including 9.8p1
Additional details
Details are emerging about this research, but it appears that CVE-2024-6387 is a regression of an earlier vulnerability for which a patch was issued in 2006 (CVE-2006-5051). What this means is that even if a company fixed this issue previously, new code changes/updates have reintroduced the vulnerability, making it necessary to find and fix. According to the Qualys researchers, OpenBSD systems are not vulnerable to this flaw.
While security media often panics at the latest news, it’s important to remember that a systematic approach to vulnerability remediation can mitigate much of the potential. The best course of action for the OpenSSH vulnerability is to patch the affected versions in your systems, especially because a successful compromise of CVE-2024-6387 could provide full system access to attackers, allowing them to execute arbitrary code, leverage highly privileged access, and maintain persistence.
Playbook — Don’t panic
First and foremost, security teams must be able to identify whether their organizations’ systems are at risk. To do this, OX Security customers can log into the OX platform and navigate to the SBOM page where they will be able to see full details about the contents of their software libraries.
On the library search on the top right-hand portion of the screen, type ‘openssh’ to see all identified instances of OpenSSH libraries in your environment. This list will include the version numbers so you can easily select the vulnerable versions.
or you can search and set response into motion by creating this workflow….
From here, install the specified OS patch.
Further, OX Security researchers recommend revisiting network access controls across your system to ensure SSH is limited. Continuous monitoring for newly identified CVEs — in particular, ones that could cause significant disruption to your business — is a critical element of your AppSec program.
If you are not an OX customer, sign up for a free trial and get started in less than five minutes. To learn more about how to eliminate manual AppSec for your organization, you can also request a demo.
