regreSSHion (CVE-2024-6387)

An unauthenticated Remote Code Execution (RCE) vulnerability in OpenSSH’s server. This flaw allows full root access to an attacker and affects the default configuration without needing user interaction making it a serious security risk.

The current vulnerability is named regreSSHion (CVE-2024-6387) because it references its nature as a regression bug affecting OpenSSH. It was recently reintroduced and is a regression of the previously patched vulnerability CVE-2006-5051 reported in 2006. A regression is a flaw once fixed that reappears in a subsequent software release typically due to changes or updates that inadvertently reintroduce the issue. This regression was introduced in October 2020 (OpenSSH 8.5p1).

By estimation there are more than 14 million potentially vulnerable Open SSH server instances exposed to the internet. To check if your asset is vulnerable to the regreSSHion vulnerability, enter your IP address or domain name here and receive your inspection results immediately from BreachLock.

CVE-2024-6387 Explained

This vulnerability is classified as a race condition, which is a bug (8.1 CVSS score), and is more specifically a signal handler race condition in OpenSSH’s servers (sshd). It affects glibc-based Linux systems running sshd in its default configuration; it may also exist in non-LIBC and 64-bit environments though exploitability for those has not been proven yet (see “affected versions” for more details).

The regreSSHion vulnerability if exploited could lead to a full system compromise where an attacker can execute arbitrary code with the highest privileges resulting in a complete system takeover installation of malware data manipulation and the creation of backdoors for persistent access.

A race condition happens when operations rely on the timing of events. An analogy would be two people trying to write on the same piece of paper at the same time. Without agreements on who will write when mistakes will be made. This often occurs in software when working with shared resources such as data or file handlers.

The race condition was discovered in the signal handler (SIGALRM) called when a client fails to authenticate within the LoginGraceTime period which specifies the time allowed for successful authentication to the SSH server. The SIGALRM handler is called asynchronously.

The problem occurs when the handler at play calls functions that are not async-signal-safe such as syslog(). In this case if multiple SSH connections forgot the LoginGraceTime period the SIGALRM handler would be called multiple times flooding the syslog() function.

Syslog() itself calls async-signal-unsafe functions (for example malloc() and free()): an unauthenticated remote code execution as root because it affects sshd’s privileged code which is not sandboxed and runs with full privileges.

Although exploitation still has its limitations, our SAM Engine will verify your SSH service for the presence of the race condition.

How It Happened

The OpenSSH team accidentally reintroduced the flaw that had previously been patched demonstrating that every team needs fully automated testing that runs with every build and helps prevent regressions. The vulnerability is challenging to exploit according to researchers but also is not easy to fully remediate demanding a focused and layered security approach.

The fix is part of a minor update introducing some potentially incompatible changes. Consequently users will have two update options: upgrade to the latest version released on Monday July 1st (9.8p1), or apply a fix to the older versions as outlined in the advisory.

Which SSH Versions are Impacted by the RegreSSHion Vulnerability?

OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.

The regreSSHion vulnerability resurfaces in versions from 8.5p1 up to but not including 9.8p1 due to the accidental removal of a critical component in a function.

There, however seem to be some exceptions. According to release notes for OpenSSH 9.8/9.8.1 successful exploitation has been limited to 32-bit systems so far and only produced in a lab environment:

• Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with Address space layout randomization (ASLR). Under lab conditions the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It’s likely that these attacks will be improved upon.

Remediation & Recommendations for the RegreSSHion Vulnerability

OpenSSH has released version 9.8/9.8.1 which addresses the race condition.

• Set LoginGraceTime to 0 in /etc/ssh/sshd_config. This, however, makes sshd vulnerable to a denial of service and should be a temporary measure.
• Limit SSH access through network-based controls such as VPNs to minimize the attack risks.
• Segment networks in order to restrict unauthorized access and lateral movements within critical environments.
• Deploy systems to monitor and alert on unusual activities indicative of exploitation attempts.

About BreachLock

BreachLock is a global leader in Continuous Attack Surface Discovery and Penetration Testing. Continuously discover, prioritize, and mitigate exposures with evidence-backed Attack Surface Management, Penetration Testing, and Red Teaming.

Elevate your defense strategy with an attacker’s view that goes beyond common vulnerabilities and exposures. Each risk we uncover is backed by validated evidence. We test your entire attack surface and help you mitigate your next cyber breach before it occurs.

Know your risk. Contact BreachLock today!

Sources

1. https://github.com/zgzhang/cve-2024-6387-poc/blob/main/7etsuo-regreSSHion.c
2. https://github.com/acrono/cve-2024-6387-poc
3. https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
4. https://www.openssh.com/txt/release-9.8