Critical OpenSSH Flaw Discovered

The OpenSSH maintainers have recently issued security upgrades to address a severe security vulnerability that could potentially lead to unauthorized remote code execution with root privileges in Linux systems based on the glibc library.

The vulnerability, known as regreSSHion, has been designated with the CVE identifier CVE-2024-6387. It is present in the OpenSSH server component, commonly referred to as sshd, which is designed to accept connections from various client programs.

According to Bharat Jogi, senior director of the threat research unit at Qualys, “The vulnerability in OpenSSH’s server (sshd) is a signal handler race condition. This vulnerability enables unauthenticated remote code execution (RCE) as root on Linux systems that are based on glibc,” stated the disclosure published today. “The race condition impacts the sshd service when it is used with its default settings.”

You might be interested in: Intel CPUs Affected by New UEFI Vulnerability

The OpenSSH maintainers have issued security upgrades to address this major security vulnerability that could potentially allow unauthorized remote execution of code with root privileges in Linux systems based on glibc.

The vulnerability, known as regreSSHion, has been assigned the CVE identifier CVE-2024-6387. It is found in the OpenSSH server component, commonly referred to as sshd, which is designed to accept connections from various client programs.

“According to Bharat Jogi, senior director of the threat research unit at Qualys, the vulnerability in OpenSSH’s server (sshd) is a signal handler race condition. This vulnerability enables unauthenticated remote code execution (RCE) as root on Linux systems that are based on glibc,” stated the disclosure published today. “This race condition impacts the sshd service when it is operating with its default settings.”

The cybersecurity company reported the discovery of at least 14 million OpenSSH server instances that are potentially vulnerable and accessible on the internet. This represents a recurrence of a previously fixed flaw first identified 18 years ago, known as CVE-2006-5051. The issue resurfaced in October 2020 with the release of OpenSSH version 8.5p1.

OpenSSH stated in an advisory that they have successfully proven the exploitation on 32-bit Linux/glibc platforms with address space layout randomization. “In controlled laboratory settings, the attack typically necessitates an average duration of 6-8 hours of uninterrupted connections, reaching the maximum limit that the server can handle.”

The issue affects versions ranging from 8.5p1 to 9.7p1. Versions earlier than 4.4p1 are susceptible to the race condition flaw unless they have been fixed for CVE-2006-5051 and CVE-2008-4109. OpenBSD systems are not affected by the issue since they have a security mechanism in place that prohibits it.

The security vulnerability is expected to impact both macOS and Windows; however, its ability to be exploited on these platforms has not been validated and requires further investigation. Qualys discovered that if a client fails to authenticate within 120 seconds, as determined by the LoginGraceTime parameter, sshd’s SIGALRM handler is invoked in an asynchronous way that is not compatible with async-signal-safe operations.

Exploiting CVE-2024-6387 results in a complete breach and takeover of the system, allowing threat actors to run any code with the highest privileges, bypass security measures, steal data, and maintain long-term access.

“According to Jogi, a flaw that was previously resolved has resurfaced in a later version of the software, usually because of modifications or updates that unintentionally reintroduce the problem,” the disclosure states. “This incident emphasizes the importance of conducting comprehensive regression testing to avoid the reintroduction of previously identified vulnerabilities into the system.”

Although the vulnerability is hindered by major obstacles due to its nature as a remote race condition, it is advisable for users to install the most recent fixes to protect themselves from potential risks. It is recommended to restrict SSH access using network-based controls and implement network segmentation to prevent unauthorized access and lateral movement.