Researchers have warned of a critical vulnerability affecting the OpenSSH networking utility that could be used to give attackers full control over Linux and Unix servers without the need for authentication.
The vulnerability, tracked as CVE-2024-6387, allows unauthenticated remote code execution with root privileges on Linux systems that are based on glibc, an open source implementation of the C standard library. The vulnerability is the result of a code regression introduced via 2020, which reintroduced CVE-2006-5051, a vulnerability that was patched in 2006. With thousands, if not millions, of vulnerable servers populating the Internet, this latest vulnerability could pose a significant risk.
Full system takeover
“This vulnerability, if exploited, could lead to full system compromise where an attacker could execute arbitrary code with elevated privileges, resulting in full system takeover, installation of malware, manipulation of data, and creation of persistent access backdoors,” wrote Bharat Jogi, senior director of threat research at Qualys, the security firm that discovered it. “This can facilitate network propagation, allowing attackers to use a compromised system as a foothold to bypass and exploit other vulnerable systems within the organization.”
The risk is due in part to the central role that OpenSSH plays in almost every internal network connected to the Internet. It provides a channel for administrators to connect to protected devices remotely or from one device to another on the network. OpenSSH’s ability to support multiple strong encryption protocols, its integration into nearly all modern operating systems, and its location at the very perimeter of networks further fuel its popularity.
In addition to the ubiquity of vulnerable servers populating the Internet, CVE-2024-6387 also provides a powerful means of executing malicious code with the highest privileges, without the need for authentication. The flaw stems from mishandling the signal handler, a component in glibc for reacting to potentially serious events, such as attempts to divide by zero. When a client device initiates a connection but does not successfully authenticate within the specified time (120 seconds by default), vulnerable OpenSSH systems call what is known as a SIGALRM handler asynchronously. The vulnerability resides in sshd, the core engine of OpenSSH. Qualys named the vulnerability regreSSHion.
The severity of the threat posed by the exploit is significant, but various factors are likely to prevent its widespread exploitation, security experts said. First, the attack could take up to eight hours to complete and require up to 10,000 authentication steps, said Stan Kaminski, a researcher at security firm Kaspersky. The delay is the result of a defense known as address space layout randomization, which changes the memory addresses where executable code is stored to thwart attempts to launch malicious payloads.
Other restrictions apply. Attackers also need to know the specific operating system running on each target server. So far, no one has found a way to use 64-bit systems because the number of available memory addresses is exponentially higher than what is available for 32-bit systems. Further reducing the chances of success, denial-of-service attacks that limit the number of connection requests coming into a vulnerable system will prevent exploitation attempts from succeeding.
All of these limitations will likely prevent CVE-2024-6387 from being widely exploited, the researchers said, but there is still a risk of targeted attacks that flood a specific network of interest with authentication attempts for several days while allowing code to execute . To cover their tracks, attackers can spread requests across a large number of IP addresses in a manner similar to password spraying attacks. In this way, attackers could target a handful of vulnerable networks until one or more attempts fail.
The vulnerability affects the following:
- Versions of OpenSSH earlier than 4.4p1 are vulnerable to this signal handler race condition unless fixed for CVE-2006-5051 and CVE-2008-4109.
- Versions 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative fix for CVE-2006-5051 that made a previously vulnerable feature secure.
- The vulnerability reappeared in versions 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.
Anyone using a vulnerable version should update as soon as possible.
