Labeled as CVE-2024-6387, the recently discovered vulnerability in OpenSSH has become a serious cause for concern among Linux servers. OpenSSH is a collection of networking tools built on the Secure Shell (SSH) protocol. It is widely utilized to secure remote logins, manage and administer remote servers, and transfer files through SCP and SFTP.
Nicknamed as the “RegreSSHion Bug”, Researchers at Qualys initially identified the vulnerability in May 2024. This flaw permits remote code execution (RCE), which can lead to attackers obtaining root access to the system.
The term “RegreSSHion” is a combination of “regression” and “SSH.” It denotes a regression or decline in the software’s functionality or security, affecting SSH (Secure Shell), a protocol used to securely access network services over an insecure network. The name humorously emphasizes that the bug represents a backward step (regression) in the performance or security of SSH.
Step-by-Step Breakdown of How Attackers are
Exploiting this Flaw
Researchers at Qualys have identified a vulnerability in the OpenSSH server process (sshd) susceptible to a signal handler race condition. This flaw allows unauthenticated remote code execution with root privileges on glibc-based Linux systems when configured by default. OpenSSH, known for its open-source suite facilitating remote sign-in and data transfer via the Secure Shell (SSH) protocol, is at risk.
The root cause is that the sshd privilege code operates with full privileges and is not sand-boxed. Notably, OpenBSD is not affected due to its signal alarm (SIGALRM) handler employing syslog_r(), an async-signal-safe variant of syslog().
The exploit’s effectiveness depends on hitting a precise time-frame. According to Qualys research:
- It takes roughly 10,000 attempts to successfully trigger the race condition.
- With 100 connections (MaxStartups) allowed every 120 seconds (LoginGraceTime), it typically takes about 3-4 hours to succeed.
- Considering the need to bypass ASLR (Address Space Layout Randomization), a full exploit to achieve remote root access might take around 6-8 hours.
The timing is critical because the exploit must disrupt specific operations at the exact right moment to alter the system’s memory state. Regarding OS and architecture, the Proof of Concept (PoC) primarily targets 32-bit (x86) systems, but work on a 64-bit (amd64) version was underway. For SSDH on i386, glibc is always mapped on a predictable address (0xb7200000 or 0xb7400000), which is why attacks on 32 bit systems are easier!
“If this vulnerability is exploited, it could allow an attacker to execute arbitrary code with elevated privileges, leading to full system compromise. This means an attacker could completely take over the system, install malware, manipulate data, and create backdoors for ongoing access.”
– Qualys Team
Active Exploitation of CVE-2024-6387 in the Wild: Remain Vigilant but Don’t Panic!
Although a PoC code exists for this vulnerability, there have been no reported instances of its use in the wild as of July 2, 2024. Testing this code in various environments may show that it is non-functional. Researchers could not use the PoC to exploit the CVE-2024-6387 vulnerability for remote code execution.
Fortunately, the complexity of the attack results in a prolonged exploitation process. The Qualys Threat Research unit has reported success in exploiting only 32-bit systems, requiring around 10,000 connections and 6-8 hours when targeting the latest Debian version in a controlled lab setting.
No successful exploitation of 64-bit systems has been reported so far, likely due to the significantly increased complexity and time required. Estimates show that exploiting a 64-bit system would take less than a week.
Proof of concept code has been publicly shared on GitHub. Although the Wallarm Team believes that a real-world exploitation of 64-bit systems is unlikely, we updated all OpenSSH servers promptly to ensure our infrastructure remains protected.
Mitigation: Patch, Updates, and Recommendations
The OpenSSH team has released an update to mitigate this vulnerability. Users are strongly advised to upgrade to the latest OpenSSH version to protect against potential exploits. This update involves improvements in the management of PKCS#11 providers and enhancements to the security checks within the SSH-agent code.
- Upgrade OpenSSH: Ensure you are using the latest OpenSSH version by applying the updates from your Linux distribution.
- Restrict SSH-agent Forwarding: Limit the usage of SSH-agent forwarding to only trusted hosts and necessary scenarios.
- Monitor and Audit: Regularly audit SSH configurations and monitor usage to detect any suspicious activities.
- Restrict direct network/internet access to SSH interfaces: Remote management interfaces should be accessible only via secure VPN channels. This measure significantly decreases attack surfaces and improves resistance against potential new vulnerabilities including zero-days.
OpenSSH versions earlier than 4.4p1 are susceptible unless patched for CVE-2006-5051 and CVE-2008-4109. Versions between 8.5p1 and 9.8p1 are also at risk. Versions 4.4p1 to 8.5p1 are safe due to the standard patching of CVE-2006-5051.
Qualys advised organizations not only to apply these patches but also to restrict SSH access through network controls, segment networks, and deploy monitoring systems to detect exploit attempts.For further instructions on updating OpenSSH and additional security measures, refer to the official OpenSSH release notes and advisories from your Linux distribution.