regreSSHion: CVE-2024-6387 OpenSSH Vulnerability Explained and How to Patch It

In July 2024, Qualys researchers disclosed CVE-2024-6387, dubbed “regreSSHion” — a critical unauthenticated remote code execution (RCE) vulnerability in OpenSSH’s server (sshd). The bug affects glibc-based Linux systems and represents the first OpenSSH RCE in nearly 20 years. With over 14 million internet-exposed OpenSSH servers at the time of disclosure, the potential impact is massive.

What Is regreSSHion?

regreSSHion is a signal handler race condition in OpenSSH’s server. Specifically, it’s a regression of CVE-2006-5051 — a bug that was fixed in 2006 but was accidentally reintroduced in OpenSSH 8.5p1 (released in 2021).

The vulnerability exists in the SIGALRM handler. When a client fails to authenticate within the LoginGraceTime (default: 120 seconds), the server calls cleanup_exit() from an async-signal context. This is a classic async-signal-safety violation that can lead to heap corruption — and ultimately to remote code execution as root.

Who Is Affected?

# Vulnerable OpenSSH versions on glibc-based Linux:
OpenSSH 8.5p1 through 9.7p1

# Check your version:
ssh -V
# Example output: OpenSSH_9.2p1 Ubuntu-2ubuntu0.2

# Specifically NOT vulnerable:
# - OpenBSD (different signal handling)
# - macOS (uses different libc)
# - OpenSSH < 4.4p1 (different code path)
# - OpenSSH >= 9.8p1 (patched)

# Check if your system is exposed:
sudo ss -tlnp | grep :22
# If sshd is listening on 0.0.0.0:22 or :::22, you're exposed

How the Exploit Works (Technically)

The exploit is a heap-based buffer overflow triggered through race conditions in malloc/free calls within the SIGALRM handler. Exploitation requires:

Approximately 10,000 authentication attempts to win the race condition
ASLR must be defeated (possible through brute-force on 32-bit systems, harder on 64-bit)
Remote code execution as root if successful

# The vulnerable code path (simplified):
# In sshd/session.c - signal handler calls async-unsafe functions:

static void
grace_alarm_handler(int sig)
{
    /* This calls cleanup_exit() from signal handler context */
    /* cleanup_exit() calls malloc/free — NOT async-signal-safe! */
    cleanup_exit(255);  // <-- ROOT CAUSE
}

# A patched version would look like:
static void
grace_alarm_handler(int sig)
{
    /* Safe: just set a flag, handle in main loop */
    grace_alarm_fired = 1;
}

Immediate Mitigation Steps

Step 1: Patch OpenSSH (Priority #1)

# Ubuntu/Debian — update OpenSSH:
sudo apt update && sudo apt upgrade openssh-server
# Verify patched version (>= 9.8p1 OR distro backport):
ssh -V

# RHEL/CentOS/Rocky/AlmaLinux:
sudo dnf update openssh-server
# Red Hat released backported patches:
# RHEL 9: openssh-8.7p1-38.el9 or later
# RHEL 8: openssh-8.0p1-25.el8 or later

# Check patch status on Debian/Ubuntu:
apt-cache policy openssh-server

Step 2: Workaround (If Patching Is Delayed)

# Set LoginGraceTime to 0 to disable the vulnerable code path:
sudo nano /etc/ssh/sshd_config

# Add or modify:
LoginGraceTime 0

# This disables the grace period timer entirely
# Downside: no protection against half-open connection DoS

# Restart SSH (ensure you have console access before doing this!):
sudo systemctl restart sshd

Step 3: Network-Level Mitigations

# Restrict SSH access with firewall:
# UFW:
sudo ufw allow from 203.0.113.0/24 to any port 22  # Only trusted IPs
sudo ufw deny 22

# iptables:
iptables -A INPUT -p tcp --dport 22 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

# Add rate limiting to slow exploitation attempts:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

Detection: Was Your Server Exploited?

# Check auth logs for massive authentication failures (exploit requires ~10k attempts):
# Ubuntu/Debian:
sudo grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head 20

# RHEL/CentOS:
sudo grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -rn | head 20

# Look for: single IP with thousands of attempts in short time

# Shodan check — see if your server is exposed:
# Search on shodan.io: port:22 product:OpenSSH version:9.2
# If you find your server, that's your attack surface

# Monitor with Wazuh rule:
# Rule 5710/5712 fires on excessive SSH authentication failures
sudo tail -f /var/ossec/logs/alerts/alerts.log | grep "5710|5712"

Scanning Your Infrastructure

# Nuclei template for CVE-2024-6387:
nuclei -t cves/2024/CVE-2024-6387.yaml -u ssh://target-ip:22

# Or check version with nmap:
nmap -sV -p 22 --script=ssh2-enum-algos 192.168.1.0/24
# Look for OpenSSH versions between 8.5p1 and 9.7p1

Wrap Up

regreSSHion is a stark reminder that security regressions happen — even in critical, widely-audited software. The fix is straightforward: update OpenSSH. Do it now. If you can't patch immediately, set LoginGraceTime 0 and restrict SSH access by IP. This vulnerability is a top priority for any organization with internet-exposed SSH servers.