CVE-2024-6387 (regreSSHion): What You Need to Know

On July 1, 2024, Qualys disclosed CVE-2024-6387, a signal handler race condition in OpenSSH's server daemon (sshd) that allows unauthenticated remote code execution as root on glibc-based Linux systems. The vulnerability was nicknamed "regreSSHion" because it is a regression of CVE-2006-5051, a bug that was originally patched in 2006 and inadvertently reintroduced in October 2020 with OpenSSH 8.5p1.

This is the first unauthenticated RCE in OpenSSH in nearly two decades. Given that OpenSSH is installed on virtually every Linux server on the internet, the blast radius is enormous. Shodan queries at the time of disclosure showed over 14 million potentially vulnerable OpenSSH instances exposed to the internet.

What Is the Vulnerability?

The vulnerability exists in the SIGALRM signal handler within sshd. When a client connects to an OpenSSH server, the server starts a timer (controlled by the LoginGraceTime setting, which defaults to 120 seconds). If the client does not authenticate within this window, the server's SIGALRM handler fires to clean up the connection.

The problem is that this signal handler calls functions that are not async-signal-safe, including syslog(), which internally calls malloc() and free(). If the signal fires at precisely the right moment -- while malloc() or free() is already executing in the main program flow -- the handler corrupts the heap. An attacker can exploit this heap corruption to achieve arbitrary code execution.

Because the signal handler runs in the context of sshd, which typically runs as root, successful exploitation gives the attacker root-level access to the system without ever providing credentials.

Who Is Affected?

The vulnerability affects OpenSSH versions based on these ranges:

Important caveats:

• The exploit demonstrated by Qualys specifically targets glibc-based Linux systems (32-bit). Exploitation on 64-bit systems is theoretically possible but was not demonstrated and would be significantly more complex.
• OpenBSD is not affected -- OpenBSD's implementation of the signal handler has been safe since 2001.
• Systems using musl libc (Alpine Linux, for example) are not affected by the demonstrated exploit path.

How to Check If You Are Vulnerable

Run the following command on any system running sshd:

sshd -V

Note: on many systems, sshd -V outputs the version to stderr. If you see no output, try:

ssh -V

This shows the client version, which is typically the same as the server version when installed from the same package. For a definitive check on the server:

# Check the package version directly
# Debian/Ubuntu:
dpkg -l openssh-server

# RHEL/CentOS/Fedora:
rpm -q openssh-server

If your version falls between 8.5p1 and 9.7p1 (inclusive), you are running a vulnerable version.

You can also check remotely by connecting to the SSH port and reading the banner:

nc -w 3 target-host 22

The server will typically respond with a string like SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13, which reveals the version.

Remediation

Option 1: Update OpenSSH (Recommended)

Update to OpenSSH 9.8p1 or later. This is the definitive fix.

# Debian/Ubuntu:
sudo apt update && sudo apt upgrade openssh-server

# RHEL/CentOS/Fedora:
sudo dnf update openssh-server

# Then restart the service:
sudo systemctl restart sshd

Most major distributions shipped patched packages within days of the disclosure. Check your distribution's security tracker if you are unsure whether the fix has been backported to your current version.

Option 2: Temporary Mitigation

If you cannot update immediately, set LoginGraceTime to 0 in your sshd configuration:

# In /etc/ssh/sshd_config:
LoginGraceTime 0

Then restart sshd:

sudo systemctl restart sshd

Trade-off: Setting LoginGraceTime to 0 disables the login timeout entirely, meaning the server will not automatically drop unauthenticated connections. This makes sshd vulnerable to connection exhaustion (denial of service) because an attacker can open many connections that never complete authentication. This is a less severe risk than unauthenticated RCE, so the trade-off is generally acceptable as a temporary measure. Mitigate the DoS risk with MaxStartups rate limiting.

Option 3: Network-Level Mitigation

Restrict SSH access at the network level to known IP ranges using firewall rules or security groups. This does not fix the vulnerability but reduces the attack surface to only those who can reach port 22.

# iptables example - only allow SSH from your office IP:
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

How the Exploit Works (Technical Details)

The Qualys research team demonstrated exploitation on 32-bit Linux systems with glibc. The attack works as follows:

1. The attacker opens a connection to sshd. The LoginGraceTime timer starts (default 120 seconds).
2. The attacker sends carefully crafted partial authentication data designed to put malloc() or free() in a specific state within the heap.
3. The timer expires. The SIGALRM signal fires. The signal handler calls syslog(), which calls malloc()/free().
4. The heap corruption occurs. Because malloc() was already in the middle of an operation when the signal fired, the concurrent free() call in the handler corrupts heap metadata.
5. The attacker leverages the corruption to overwrite function pointers or other critical data structures, achieving code execution as root.

In Qualys's lab environment, exploitation required approximately 10,000 attempts on average, which translates to roughly 6-8 hours against the default LoginGraceTime of 120 seconds. This is noisy and detectable, but the key point is that it is reliable -- given enough time, exploitation succeeds.

Detection

Look for signs of exploitation attempts in your SSH logs:

# Check for repeated connection timeouts from the same IP:
grep "Timeout before authentication" /var/log/auth.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

A single IP generating hundreds or thousands of authentication timeouts is a strong indicator of exploitation attempts. Normal users do not fail to authenticate thousands of times in a row.

Network-level detection can look for:

• High volume of SSH connections from a single source that do not complete authentication
• Connections to port 22 that last exactly 120 seconds (the default LoginGraceTime) before being terminated
• Unusual patterns in SSH handshake data

How CELVEX Group Detects This

Our external attack surface scanning pipeline includes automated detection for CVE-2024-6387. When we scan a target domain, we enumerate all hosts and check for SSH services. For each SSH service found, we:

1. Capture the SSH banner to identify the OpenSSH version
2. Cross-reference against the known vulnerable version ranges
3. Check whether the LoginGraceTime mitigation appears to be in place (by timing connection behavior)
4. Flag affected hosts with severity ratings based on exposure level (internet-facing vs. internal)

In our recent scan of 50 companies, multiple organizations were running vulnerable OpenSSH versions on internet-facing hosts. Several had not patched more than six months after the initial disclosure -- a timeline that gives any motivated attacker more than enough time to exploit the vulnerability.