What is CVE-2024-6387? Understand RegreSSHion, the OpenSSH vulnerability

There’s a good reason why CVE-2024-6387, a new critical vulnerability affecting OpenSSH, is keeping the security community on edge - and we’re about to unpack and explain them.

Codenamed regreSSHion, this critical security flaw got recently discovered by the threat research unit at Qualys. CVE-2024-6387 allows remote, unauthenticated attackers to execute remote code on the target with unsandboxed root privileges in glibc-based Linux Systems.

This is the second time this year OpenSSH has been hit with a critical vulnerability, after the XZ Utils backdoor swept through the tech world in March.

While XZ Utils affected a limited number of versions and required an especially crafted certificate that only the threat actor owned, this time the vulnerability affects a wider range of versions which any agent with a working POC (Proof of Concept) can exploit.

Qualys chose not to disclose the POC for CVE-2024-6387, but there are already public attempts at crafting one based on their whitepaper. At the time of writing this article, a working POC was yet to be confirmed.

If you're looking for a quick way to

What is CVE-2024-6387 (RegreSSHion)?

This vulnerability is a regression (hence the codename) of CVE-2006-5051, a "Signal handler race condition in OpenSSH before 4.4 that allows remote attackers to cause a denial of service (crash), and possibly execute arbitrary code." 

This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit 752250c ("revised log infrastructure for OpenSSH"), which accidentally removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function that is directly called by SSHD's SIGALRM handler.  As a consequence, if a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then SSHD's SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe (for example, syslog()). This race condition affects SSHD in its default configuration.

Does RegreSSHion (CVE-2024-6387) affect my targets?

The OpenSSH versions which CVE-2024-6387 affects are:

• OpenSSH < 4.4p1 - which is vulnerable to this signal handler race condition, if not backport-patched against CVE-2006-5051, or not patched against CVE-2008-4109, which was an incorrect fix for CVE-2006-5051;

• OpenSSH 4.4p1 through  8.5p1 is not vulnerable to this signal handler race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added to sigdie() by the patch for CVE-2006-5051 transformed this unsafe function into a safe _exit(1) call);

• OpenSSH 8.5p1 through 9.8p1 is vulnerable again to this signal handler race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was accidentally removed from sigdie()).
  

To keep our feet firmly on the ground, please note that:

• For the moment, the vulnerability only affects glibc-based Linux systems; the Qualys Threat Research Unit estimates there are over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet;

• OpenBSD systems are unaffected by this security issue;

• The whitepaper from Qualys explains the exploit process only for i386 systems. They started working on an exploit for modern AMD64 systems. This will be harder to achieve because of the stronger ASLR.

The technical details of how CVE-2024-6387 appeared

The RegreSSHion exploit idea

This commit modified the sigdie function. Most notably it renamed it to sshsigdie and removed #ifdef DO_LOG_SAFE_IN_SIGHAND, allowing do_log to execute in any context.

In turn, syslog() gets called, which calls malloc() if the syslog() inside the SIGALRM handler is the very first call to syslog().  

Malloc is async-unsafe, which leads to a race-condition vulnerability that allows attackers to interrupt the malloc operation using SIGALRM and leave the heap in an inconsistent, exploitable state. 

By precisely timing the delivery of SIGALRM during specific malloc() operations, attackers can corrupt heap structures and execute arbitrary code by manipulating the  FILE structure.

Threat actors can achieve this by overwriting a single byte (_vtable_offset) of the malloc()ated FILE structure and then calling a user controlled fct function pointer and executing arbitrary code during fread_unlocked().

Exploit timing to leverage RegreSSHion

By sending especially crafted public keys, an attacker can trigger two different errors, which help narrow down the time it takes for SSHD to parse the most recently sent public key. With this strategy, it takes ~10,000 tries on average to win the race condition. (Keep this number in mind for later.)

Defeating ASLR to exploit CVE-2024-6387 

Address space layout randomization (ASLR) is a mechanism which tries to defeat heap corruption vulnerabilities. It does so by randomly arranging the address space positions of key data areas of a process. However, the target version of Debian i386, suffers from an ASLR weakness.

TL;DR: for SSDH on i386, glibc is always mapped either at address 0xb7200000 or 0xb7400000. This allows an attacker to correctly guess the address half of the time. 

Qualys suggested that, from their studies, the address 0xb7400000 is slightly more probable than 0xb7200000.

This last piece of the puzzle allows attackers to build a successful exploit.

This also means that, to win the race condition and defeat ASLR, an attacker requires ~20,000 tries. With 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime) an attacker needs ~6-8 hours to get a remote shell. 

If the target has different configurations, the number of hours can be different. To estimate the number of hours you’d need to exploit a particular configuration, you can use this formula:

(20,000 / MaxStartups * LoginGraceTime) / 3600

❗️Please, keep in mind this formula only applies for the Debian i386 systems on which the original research was conducted.

Patching and mitigating against RegreSSHion (CVE-2024-6387)

The best course of action is to update OpenSSH to version ​​9.8p1, a patch which fixes this issue, and provides a larger defense-in-depth approach.

If updating is not possible, you can fix the vulnerability by manually disabling the async-signal-unsafe code from the log.c:sshsigdie function.

If there’s no way to update or recompile SSHD, you can still fix the race-condition issue by setting LoginGraceTime to 0 in the configuration file. However, this is a last resort approach, as this change will make SSHD prone to Denial Of Service attacks, opening a different can of worms.

Source

Just like with the XZ Utils Backdoor, we’ll keep you posted on this topic and update this article with the latest technical insights. 

In the meantime, our team has created a dedicated scanner for RegreSSHion, which you can use with no strings attached (no, we don't even ask for your email):

Here's what the evidence looks like:

Thanks for reading and hope this CVE doesn’t make your job more challenging than it already is!