Introduction

On July 1, 2024, the Qualys Threat Research Unit disclosed a critical flaw in the OpenSSH server process, sshd, affecting glibc-based Linux systems. Tracked as CVE-2024-6387 and named regreSSHion, the flaw allows an unauthenticated remote attacker to execute arbitrary code with root privileges. What sets this case apart from most vulnerability disclosures is the name itself: regreSSHion is a regression, a flaw that was already found and fixed once, in 2006, before quietly reappearing eighteen years later.

What is CVE-2024-6387?

CVE-2024-6387 is a race condition in the signal handler of the OpenSSH server. A race condition occurs when multiple processes access and modify shared data at the same time, producing unpredictable results depending on the order those operations happen to complete in. Here, the race sits inside the function that handles a specific signal sent to the server process.

A Regression, Not a New Flaw

The underlying issue was first identified as CVE-2006-5051 and patched that year. The fix made a set of functions safe to call from within a signal handler, closing the race condition. That fix held for over a decade, until OpenSSH 8.5p1, released in October 2020, made changes to the logging code that inadvertently removed the safeguard. The old vulnerability came back without anyone intending it to. Versions from 8.5p1 up to but not including 9.8p1 are affected. Versions earlier than 4.4p1 are also vulnerable unless separately patched against the original 2006 issue, while versions from 4.4p1 up to 8.5p1 remained safe throughout, since the original fix was still in place during that window. OpenBSD systems were never affected, having implemented an unrelated, inherently safer mechanism back in 2001.

How Does It Work?

OpenSSH's server includes a setting called LoginGraceTime, the amount of time a connecting user has to authenticate before being disconnected. The default is 120 seconds. If authentication doesn't complete in that window, the server sends itself a SIGALRM signal to terminate the connection, which triggers the signal handler.

The problem is that OpenSSH's signal handler calls certain functions, including syslog, that aren't safe to call from within a signal handler. These are known as async-signal-unsafe functions, and calling them in this context can produce unpredictable behavior, including memory corruption, if the timing lines up in a specific, narrow way.

Exploitation in Practice

Qualys built a working exploit to confirm the vulnerability. They demonstrated it privately to the OpenSSH team, but chose not to publish the exploit itself to give administrators time to patch before technical details became widely available. Exploiting the flaw in practice means repeatedly opening connections and letting them time out, attempting to land inside the narrow race window purely by chance across a large number of attempts. This makes the vulnerability real and serious, rated 8.1 on the CVSS scale by multiple vendors, but not trivial to exploit reliably compared to a flaw that can be triggered on the first attempt.

Potential Impact

Mitigation and Prevention

  1. Apply the patch. OpenSSH maintainers released fixed versions promptly; upgrading to 9.8p1 or later resolves the issue directly.
  2. Where patching isn't immediately possible, set LoginGraceTime to 0 in the sshd configuration. This removes the window the race condition depends on.
  3. Restrict SSH access to trusted networks using firewalls and network access controls, reducing the pool of attackers who can attempt the exploit at all.
  4. Monitor SSH logs for unusual connection patterns, particularly large numbers of connections that repeatedly time out without authenticating.

Conclusion

CVE-2024-6387 is a serious flaw precisely because of how ordinary its cause was: a logging change made six years ago, with no apparent connection to authentication security, silently undid a fix for a problem already solved in 2006. That's a useful case study on its own, since it shows how a regression can hide in plain sight inside a codebase for years before anyone notices. Patching promptly, turning off the login grace period where patching isn't immediate, and limiting SSH exposure to trusted networks remain the most direct ways to close the gap.

Sources

Qualys Threat Research Unit, "regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH Server." blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server

Red Hat Customer Portal, official CVE-2024-6387 record. access.redhat.com/security/cve/cve-2024-6387

Palo Alto Networks Unit 42, "Threat Brief: CVE-2024-6387 OpenSSH RegreSSHion Vulnerability." unit42.paloaltonetworks.com/threat-brief-cve-2024-6387-openssh