You are currently viewing Unveiling regreSSHion: Critical OpenSSH Flaw Found In Linux Systems

Unveiling regreSSHion: Critical OpenSSH Flaw Found In Linux Systems

  • Post author:
  • Reading time:4 mins read

Linux users beware! OpenSSH flaw, a networking utility installed on every Unix and Linux system by default, is affected by a critical signal handler race condition vulnerability.

CVE-2024-6387 (with an impressive CVSS score of 8.1) is a security regression of CVE-2006-5051, which highlighted a similar signal handler race condition in OpenSSH before version 4.4. Aptly named regreSSHion, the flaw was thought to be resolved until a change in October 2020 (OpenSSH 8.5p1) inadvertently reintroduced it by removing a critical safety check in the sigdie() function.

Technical Details

CVE-2024-6387 emerges when a client fails to authenticate within the designated LoginGraceTime (defaulted to 120 seconds, 600 in older versions). When this timeout occurs, sshd’s SIGALRM handler is triggered asynchronously. The problem lies in this handler calling functions such as syslog() that are unsafe to execute in this context, resulting in a race condition.

This vulnerability is known to impact glibc-based Linux systems. In these systems, syslog() calls functions like malloc() and free() that are unsafe within a signal handler, potentially leading to unauthenticated remote code execution as root. This occurs because sshd’s privileged code, which is not sandboxed, runs with full system privileges.

Attackers can exploit this by interrupting specific function calls at the right moment, leaving the system in an inconsistent state that can then be exploited within the SIGALRM handler. For example, interrupting memory management calls like malloc() or free() can corrupt the heap.

The saving grace for users is that exploitation takes a fair bit of time! On older systems (e.g., OpenSSH 3.4p1 on Debian 3.0r6), exploiting this flaw might take around 10,000 attempts, which translates to roughly a week with default connection settings. For intermediate versions (e.g., OpenSSH 4.2p1 on Ubuntu 6.06.1), the exploitation window shortens to about 1-2 days. For current versions (e.g., OpenSSH 9.2p1 on Debian 12.5.0), it could take 6-8 hours, considering modern defenses like Address Space Layout Randomization (ASLR).

Products Affected and Impact

Portable OpenSSH versions 8.5p1 to 9.8p1 are vulnerable.

As mentioned before, all Linux systems have OpenSSH installed by default. This means that innumerable systems around the globe are potentially impacted by this flaw.

Solutions and Mitigations

OpenSSH version 9.8p1 or later includes the fix for this vulnerability, so patch your instance! If you’re unable to update it immediately, setting LoginGraceTime to 0 in the configuration file will keep you safe from this flaw. However, this mitigation should not be treated as a permanent solution; it makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections).

Instantly Fix Risks with SanerNow Patch Management

SanerNow patch management is a continuous, automated, and integrated software that instantly fixes risks exploited in the wild. The software supports major operating systems like Windows, Linux, and macOS, as well as 550+ third-party applications.

It also allows you to set up a safe testing area to test patches before deploying them in a main production environment. SanerNow patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.

Experience the fastest and most accurate patching software here.