Overview 

The name RegreSSHion refers to a vulnerability tracked as CVE-2024-6387 within OpenSSH that enables remote code execution and potentially grants attackers root privileges on servers running the OpenSSH server. It was uncovered by the Qualys Threat Research Unit in May 2024.

RegreSSHion presents in every version of OpenSSH stretching from 8.5p1 through to 9.7p1. A fix was delivered on the day of publication in 9.8p1. At the time of publication, Qualys reported that 14 million publicly accessible OpenSSH instances could have been exposed to this threat. Responsible disclosure was practiced allowing OpenSSH contributors to develop a fix before the vulnerability was published to the public. Readers should note that Linux systems using the GNU C library – commonly referred to as glibc – as its standard C library were impacted. This leaves all other platforms invulnerable to RegreSSHion at the time of writing.

Technical Overview

A race condition in sshd’s (OpenSSH server component) signal handler sits at the core of the RegreSSHion vulnerability. Exploitation occurs when an SSH client fails to authenticate within the configured login grace period. Once the timeout occurs, sshd’s signal handler is invoked asynchronously. Functions exist within this handler that are not async safe and introduce a race condition. This vulnerability is a regression of an older vulnerability tracked as CVE-2006-5051 present in OpenSSH versions 4.4p1 and below introduced by targeting the free() function asynchronously. By removing a crucial condition that had mitigated the earlier vulnerability, CVE-2024-6387 was introduced instead targeting free() and malloc().

Impact

RegreSSHion (CVE-2024-6387) poses a critical risk to organisations running OpenSSH versions 8.5p1 through 9.7p1. By exploiting the race condition in sshd’s signal handler, attackers can execute arbitrary code remotely and potentially escalate their privileges to root on affected servers. The scope of this vulnerability is significant, as Qualys

estimated that 14 million publicly accessible OpenSSH instances were at risk when the vulnerability was disclosed.

It is important to note that only Linux distributions using the GNU C Library (glibc) are currently affected. Other platforms, which do not rely on glibc, are not impacted by RegreSSHion. Nonetheless, because OpenSSH is commonly used to administer systems remotely, a successful exploit could allow attackers to fully compromise a target server, steal sensitive data, install persistent backdoors, or move laterally across a network. Organisations using vulnerable versions of OpenSSH are therefore urged to update to OpenSSH 9.8p1 or later as soon as possible.

Vulnerability Detection

OpenSSH versions 8.5p1 through 9.7p1 are likely to contain the RegreSSHion vulnerability. However, many Linux distributions backport security patches into older versions, so merely comparing upstream OpenSSH version numbers is not a reliable way to determine whether RegreSSHion is present. In such cases, it is essential to consult the distribution’s documentation and changelogs to confirm whether the packaged OpenSSH application is vulnerable.

Exploitation  

Exploitation of RegreSSHion requires some effort with exploitation attempts potentially leaving an audit trail. Vulnerabilities introduced by race conditions can typically require multiple exploitation attempts before the desired outcome of the race condition is achieved, and RegreSSHion is no exception.

This bulletin comes after a proof-of-concept exploit was released which could increase the accessibility of this exploit and administrators should expect more exploitation attempts since the proof-of-concept was released.

Despite the discovery of the vulnerability dated around July 2024, the vulnerability was introduced into OpenSSH in October 2020 where it remained vulnerable until disclosure.

Containment, Mitigations & Remediations  

Administrators should apply patches as soon as possible to the OpenSSH application if they suspect they are vulnerable. Additionally, where patching remains difficult, it is possible to modify the login grade period to 0. However, this opens up OpenSSH servers to denial-of-service attacks and should only be considered as a temporary workaround.

Additional Information

Here is the GitHub commit that re-introduced the vulnerability.

upstream: revised log infrastructure for OpenSSH · openssh/openssh-portable@752250c · GitHub