CVE-2024-6387
RegreSSHion (Openssh Unauthenticated Remote Code Execution)

Affected Versions

• OpenSSH < 4.1p1 on Linux systems based on glibc
• OpenSSH >= 8.5p1 and < 9.8p1 on Linux systems based on glibc

Gatewatcher Product Status

Gatewatcher supported products are not affected by this vulnerability.

OpenSSH, a widely used and trusted remote administration tool, has been identified with a critical vulnerability. On July 1, 2024, researchers from Qualys announced the discovery of an unauthenticated remote code execution vulnerability in an up-to-date version of OpenSSH, even in its default configuration.

Named “regreSSHion” in reference to the fact that this vulnerability emerged following the removal of a previously implemented fix, CVE-2024-6387 is considered of high importance according to its CVSSv3.1 score (8.1).

This vulnerability is based on a race condition in the SIGALRM signal handler. This handler calls various functions that are not designed to be called asynchronously.

While the overall functioning of the vulnerability is the same in all cases, the detailed analysis published by the researchers indicates that different paths can be taken to trigger the vulnerability. These paths depend on the underlying operating system, but several paths can also coexist within the same system.

On recent operating systems, the technique involves ensuring memory organization through a series of memory allocation/release operations, which, once performed, will allow the call to malicious code.

However, as indicated in the publication, research is still ongoing, with exploitation having been successful on 32-bit systems, but exploitation on 64-bit systems taking longer.

Due to the random nature of race conditions and the presence of memory protection mechanisms such as ASLR, this attack requires numerous attempts to succeed.

According to the document detailing the vulnerability, for a recent system with the default configuration (MaxStartups 100, LoginGraceTime 120s), the estimated time to gain root access is around 6 to 8 hours.

A relatively general detection method would be a rule like this:

alert ssh any any -> any any (msg:”EVENT Possible CVE-2024-6387 exploitation attempt”; flow: established,to_server; threshold: type both, track by_both, count 100, seconds 120; reference:cve,2024-6387; metadata: created_at 2024_07_01, cve CVE_2024_6387; sid:10000001; rev:1;) 

Given the simplicity of available proof of concepts, detection rules are likely to evolve rapidly.

Update 07/02/2024: A rule has been added to the default ruleset to alert when an SSH server responds with a banner containing a vulnerable version.

However, as usual, it is strongly advised to validate the application of new rules in a pre-production environment. It is also important to remember that this potential detection does not replace the implementation of patches.

As previously mentioned, there can be many variants to achieve a similar result.

The researchers who reported the issue worked in collaboration with the OpenSSH teams, which allowed for a rapid update. Version 9.8p1 has been available since July 1, 2024.

Given the number of potentially affected systems and variations, it is necessary to check if the patch has been provided by the relevant distribution.

While the main risk is an initial compromise, it is important to keep in mind that this type of vulnerability can also allow an attacker with initial access to move laterally. Therefore, it is crucial to quickly patch all affected systems, including those not directly exposed to the internet.

A workaround to prevent exploitation of this vulnerability is to set the LoginGraceTime parameter to 0. However, note that this workaround exposes the SSH server to denial of service by using up all resources allocated to managing new connections (MaxStartups).

Finally, this vulnerability proves, if needed, that no software is immune to vulnerabilities, highlighting the importance of strong segmentation and a detection system.