An unauthenticated RCE-as-root vulnerability was identified in OpenSSH server (sshd) by researchers from Qualys, assigned CVE-2024-6387 and dubbed regreSSHion. The vulnerability is a signal handler race condition and is known to be exploitable in the default configuration of OpenSSH in specific version ranges running on 32-bit glibc-based Linux distributions.
What is CVE-2024-6387?
A signal handler race condition vulnerability was discovered in OpenSSH server (sshd) affecting its default configuration. If an SSH client fails to authenticate within the LoginGraceTime period (120 seconds by default), then the SIGALRM (signal alarm) handler is called asynchronously, but some of the functions that it calls are not async-signal-safe, including syslog(). In glibc-based Linux distros, under certain conditions syslog() calls the async-signal-unsafe functions malloc() and free() . If a call to either of these is interrupted by code that also calls a heap-related function, this could lead to heap corruption, which can be abused by arranging the heap in a way that leads to arbitrary code execution, running with sshd's root privileges.
The researchers who discovered this vulnerability analyzed the root cause and determined it to be a regression of an earlier vulnerability (CVE-2006-5051), meaning that the original vulnerability was accidentally reintroduced due to other code changes.
How likely is this vulnerability to be exploited en masse?
Based on what is currently known about this vulnerability, Wiz Research estimates that widespread exploitation is unlikely. Our reasoning is that currently known exploitations rely on distribution-specific conditions (ASLR for example) and glibc-version-specific struct layouts, which means an attacker must know in advance what Linux distribution they are targeting in order to build a functional exploit. This requirement makes the vulnerability inappropriate for widespread opportunistic exploitation.
Furthermore, successful exploitation usually takes several hours of login attempts in total. If attempted continuously by an attacker trying to successfully exploit the vulnerability as fast as possible, the exhibited behavior would be similar to that of a password brute-force attempt, meaning that any existing brute-force prevention and detection measures would effectively mitigate it, making the success rate of this technique quite low in well-protected environments.
Having said that, the exploitation process need not be continuous – since the probability of success is the same for every attempt, in theory an attacker could target a machine or set of machines over a period of several weeks, switching between multiple IP addresses between exploitation attempts, using a strategy similar to password spraying. This technique would make detection more difficult and therefore might be adopted by patient and sophisticated actors with specific target organizations in mind.
Who is Affected?
The following versions of OpenSSH are impacted by this vulnerability:
OpenSSH versions earlier than
4.4p1OpenSSH versions between
8.5p1and9.8p1(excluding)
The vulnerability is exploitable on glibc-based Linux distributions (e.g., Debian-based).
Certain Linux distributions have published advisories specifying that some of their releases are not affected by this vulnerability. Most of these are older versions that never got the vulnerable versions of OpenSSH as official package releases.
As of July 3rd, the following distro versions are unaffected:
Debian – All versions up to and including Debian 11.x (Bullseye)
RedHat (including Rocky, Alma, Oracle) – All versions up to and including Red Hat Enterprise Linux 8 are unaffected.
Ubuntu – All versions up to and including 20.04
However, patches are available for the following versions:
22.04 (Jammy) – fixed version:
1:8.9p1-3ubuntu0.1023.10 (Mantic) – fixed version:
1:9.3p1-1ubuntu3.624.04 (Noble) – fixed version:
1:9.6p1-3ubuntu13.3
Wiz Research data: what’s the risk to cloud environments?
According to Wiz data, 81% of cloud environments have at least one instance of OpenSSH in the vulnerable version range.
Has any exploitation been identified in the wild?
As of July 1st, 2024, no exploitation of this vulnerability has been identified in the wild. The vulnerability has only been proven as exploitable under lab conditions on 32-bit Linux/glibc systems (with ASLR). Exploitation on 64-bit systems has not been proven but is believed to be possible.
A basic proof of concept was published on GitHub. Because of the exploitation's extensive time requirements we couldn't yet verify the effectiveness of this code, but our analysis indicates this to be a legitimate exploitation of the vulnerability as described by Qualys researchers.
Which actions should security teams take?
Affected organizations should upgrade to the latest version of OpenSSH, while prioritizing publicly exposed instances. It is also recommended to restrict SSH access and not expose OpenSSH servers to the internet.
Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment, or the Wiz Sensor to detect exploitation attempts.
