regreSSHion: Race Condition in OpenSSH Signal Handler Allows Unauthenticated RCE

Overview

CVE-2024-6387, dubbed regreSSHion by the Qualys Research Team, is a critical unauthenticated remote code execution vulnerability in OpenSSH’s server daemon (sshd). It affects glibc-based Linux systems running OpenSSH versions 8.5p1 through 9.7p1 — and in a bitter irony, is a regression of CVE-2006-5051, a vulnerability that was originally patched 18 years ago.

The vulnerability exists in the signal handler for SIGALRM, which OpenSSH fires when a client fails to authenticate within the LoginGraceTime window (default: 120 seconds). The handler calls async-signal-unsafe functions — a class of functions that must never be called from signal handlers because they can corrupt internal glibc state when interrupted mid-execution by the signal.

With a CVSS score of 8.1 and affecting an estimated 14 million internet-exposed OpenSSH servers, this is one of the most significant vulnerabilities disclosed in 2024.

Technical Analysis

The root cause is in sshd.c. When a client connects but fails to complete authentication within LoginGraceTime, the kernel delivers SIGALRM to sshd. The registered handler, grace_alarm_handler(), calls syslog() and eventually exit() — both of which are not async-signal-safe.

/* VULNERABLE — sshd.c (pre-patch) */
static void
grace_alarm_handler(int sig)
{
    if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0) {
        /* Signal the privsep child to exit */
        kill(pmonitor->m_pid, SIGALRM);
    }
    /* This is NOT async-signal-safe */
    syslog(LOG_INFO, "Timeout before authentication for %s port %d",
        ssh_remote_ipaddr(active_state),
        ssh_remote_port(active_state));
    _exit(EXIT_AUTH_EXCEEDED);  /* _exit IS safe, but syslog is not */
}

The attack is a race condition: the attacker rapidly connects and disconnects thousands of times per second, hoping that SIGALRM fires precisely while sshd’s malloc()/free() heap management is in a vulnerable intermediate state. If the timing is right, the signal handler corrupts the heap in a way that is exploitable for arbitrary code execution in the context of the root-running sshd listener process.

Exploitation is probabilistic and slow — Qualys estimated approximately 10,000 attempts over 6–8 hours on a 32-bit system. 64-bit exploitation is theoretically possible but substantially harder due to ASLR.

Impact

An unauthenticated attacker on the network can, given sufficient time and attempts:

• Execute arbitrary code as root on the target server
• Achieve full system compromise: install backdoors, exfiltrate data, pivot into internal networks
• Bypass all authentication controls — no credentials required

The attack requires no prior access and leaves minimal traces during the connection-flood phase. Any internet-exposed SSH server with default LoginGraceTime settings is at risk.

Approximately 14 million OpenSSH instances were exposed to the internet at the time of disclosure according to Shodan data.

How to Fix It

Immediate: Upgrade OpenSSH

# Debian/Ubuntu
sudo apt update && sudo apt install openssh-server

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

# Verify version
ssh -V  # Should show 9.8p1 or later

If patching is not immediately possible, set LoginGraceTime 0 in /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
LoginGraceTime 0

This disables the grace period timer entirely, preventing SIGALRM from being raised. Note that this can allow connection resource exhaustion, so combine it with connection rate limiting:

# /etc/ssh/sshd_config
LoginGraceTime 0
MaxStartups 10:30:100   # Limit concurrent unauthenticated connections

The patch itself refactors grace_alarm_handler() to use only async-signal-safe operations:

/* FIXED — sshd.c (post-patch) */
static void
grace_alarm_handler(int sig)
{
    ostrace_disable();
    /* Set a flag only — no unsafe function calls */
    auth_timeout = 1;
    /* Use async-signal-safe _exit directly */
    _exit(EXIT_AUTH_EXCEEDED);
}

Our Take

regreSSHion is a textbook example of why regression testing for security patches is not optional. CVE-2006-5051 was fixed in OpenSSH 4.4, but the fix was accidentally reverted during a refactor in OpenSSH 8.5 (2021). The vulnerability then sat undetected for three years before Qualys found it.

For enterprises, the lesson is clear: patch management for infrastructure components must be as rigorous as application-layer dependencies. OpenSSH is on every Linux server, often treated as immutable infrastructure rather than software that needs updates.

From a SAST perspective, this vulnerability class — async-signal-unsafe functions called from signal handlers — is statically detectable. A sound SAST rule can enumerate all async-signal-unsafe functions (as defined by POSIX: malloc, free, printf, syslog, and ~100 others) and flag any call to them inside a registered signal handler.

Detection with SAST

This vulnerability class is detectable via static analysis:

1. Taint tracking from signal() / sigaction() registration to the handler body
2. Function allowlist checking — POSIX defines the complete list of async-signal-safe functions; anything not on that list called inside a handler is a finding
3. Indirect call analysis — even if the handler itself calls a “safe” wrapper, if that wrapper transitively calls an unsafe function, the vulnerability exists

Offensive360’s SAST engine flags CWE-364 (Signal Handler Race Condition) and CWE-479 (Signal Handler Use of a Non-reentrant Function) in C/C++ codebases.

References

• NVD CVE-2024-6387
• Qualys Research Blog — regreSSHion
• OpenSSH patch commit
• OpenSSH 9.8 release notes
• POSIX async-signal-safe functions