A severe Remote Unauthenticated Code Execution (RCE) vulnerability has been recently identified in OpenSSH’s server (sshd) on glibc-based Linux systems. This high-severe flaw, assigned CVE-2024-6387, poses a significant security risk as it allows unauthenticated remote code execution as root.
This discovery follows another significant vulnerability identified in the XZ Utils library just a few months ago, highlighting the ongoing challenges in cybersecurity. Although CVE-2024-6387 is a serious flaw, it is quite difficult to exploit in practice. Nonetheless, it is crucial to understand the risk and take steps to protect your systems. SSH is widely used across various platforms on Linux servers, making its security vitally important.
Technical Details
This issue arises when a client fails to authenticate within the LoginGraceTime period, which is set to 120 seconds by default in recent versions and 600 seconds in older versions. When this timeout is reached, sshd’s SIGALRM handler is triggered. The problem occurs because this handler calls various functions, such as syslog(), which are unsafe to call from within a signal handler. This race condition poses a significant risk to systems running the default sshd configuration.
Interestingly, this vulnerability is not entirely new. It is a regression of a previously identified issue, CVE-2006-5051, reported by Mark Dowd in 2006. That earlier vulnerability also involved a signal handler race condition in OpenSSH versions prior to 4.4, which could lead to a denial of service or potentially allow remote code execution.
The regression occurred in October 2020 with the release of OpenSSH 8.5p1. During an update to the logging infrastructure, a crucial directive (#ifdef DO_LOG_SAFE_IN_SIGHAND) was inadvertently removed from the sigdie() function. This function, directly called by sshd’s SIGALRM handler, was made unsafe again. Here is a breakdown of the vulnerability’s timeline:
- OpenSSH < 4.4p1: Vulnerable to the race condition unless patched for CVE-2006-5051 or CVE-2008-4109.
- 4.4p1 ≤ OpenSSH < 8.5p1: Safe due to the presence of #ifdef DO_LOG_SAFE_IN_SIGHAND, which made sigdie() call _exit(1) safely.
- 8.5p1 ≤ OpenSSH < 9.8p1: Vulnerable again due to the removal of the #ifdef DO_LOG_SAFE_IN_SIGHAND directive.
The implications of this vulnerability are particularly severe on glibc-based Linux systems, where syslog() itself may invoke other unsafe functions like malloc() and free(). This creates a scenario where an attacker can potentially execute arbitrary code as root without needing to authenticate. This is because sshd’s privileged code operates with full system privileges and lacks sandboxing.
Vulnerability Details
This vulnerability is caused by a signal handler race condition in OpenSSH’s server (sshd), which impacts systems in their default configuration. Searches using Censys and Shodan revealed over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet. Anonymized data from Qualys indicates that approximately 700,000 external internet-facing instances are vulnerable, accounting for 31% of all internet-facing instances with OpenSSH in the global customer base. Notably, over 0.14% of these vulnerable instances are running End-Of-Life/End-Of-Support versions of OpenSSH.
Exploit Development and Disclosure
By understanding the detailed exploitation process, system administrators and security professionals can better appreciate the severity of this vulnerability and the importance of implementing timely patches and robust security measures.
Exploiting the signal handler race condition vulnerability in OpenSSH requires a deep understanding of timing attacks and memory manipulation. Below, we outline the steps an attacker would take to exploit this vulnerability.
Initiate Multiple Connections
The attacker initiates numerous connections to the target OpenSSH server, repeatedly triggering the LoginGraceTime limit without completing authentication. This action causes the server to raise the SIGALRM signal.
Interrupt Signal Handler
Exploitation hinges on interrupting the server’s signal handler at the exact moment it executes non-async-signal-safe operations, such as syslog(). The attacker sends specially crafted inputs to manipulate the server’s memory layout, leading to heap corruption.
Manipulate Memory Layout
By manipulating the server’s memory, the attacker creates an inconsistent state in the heap. This is achieved by triggering the SIGALRM signal during memory allocation or deallocation functions like malloc() or free(). Exploiting this vulnerability typically requires around 10,000 attempts. Each attempt resets the LoginGraceTime timer, providing the attacker a new window to trigger the vulnerability.
Fine-tune Timing
During the exploitation process, the attacker adjusts the timing of their inputs based on feedback from previous attempts. This fine-tuning is crucial for successfully interrupting the signal handler at the critical moment. Despite modern defenses like Address Space Layout Randomization (ASLR) and No-eXecute (NX), the attacker uses predictable memory patterns and advanced timing techniques to bypass these protections.
Execute Arbitrary Code
Successful exploitation allows the attacker to overwrite critical memory structures, leading to the execution of arbitrary code and remote control of the server with root privileges.
Research and Development Insights
Researchers have primarily focused on virtual machines with mostly stable network conditions. While significant progress has been made, further improvements are anticipated, particularly for exploiting newer amd64 systems where ASLR is stronger. A related bug report discovery led to immediate communication with OpenSSH developers, underscoring the importance of swift action in addressing such vulnerabilities.
OpenSSH: Ensuring Secure Enterprise Communications
OpenSSH (Open Secure Shell) is an essential suite of secure networking utilities based on the Secure Shell (SSH) protocol. It ensures robust encryption for privacy and secure file transfers, making it vital for remote server management and secure data communication. Despite the recent vulnerability, OpenSSH remains a benchmark in software security due to its extensive security and authentication features, scalability, and ability to enforce robust access controls.
Affected OpenSSH Versions
- Vulnerable: Versions earlier than 4.4p1 (unless patched for CVE-2006-5051 and CVE-2008-4109) and versions from 8.5p1 up to, but not including, 9.8p1.
- Not Vulnerable: Versions from 4.4p1 up to, but not including, 8.5p1 due to a transformative patch for CVE-2006-5051.
OpenBSD systems are unaffected by this bug, thanks to a secure mechanism developed in 2001 that prevents this vulnerability.
Potential Impact of regreSSHion
If exploited, this vulnerability could lead to full system compromise, allowing attackers to execute arbitrary code with the highest privileges. This could result in a complete system takeover, installation of malware, data manipulation, and creation of backdoors for persistent access. It could also facilitate network propagation, enabling attackers to traverse and exploit other vulnerable systems within the organization. The remote race condition nature of this vulnerability makes it challenging to exploit, but advancements in deep learning could increase the success rate.
Immediate Steps to Mitigate Risk
- Patch Management: Quickly apply available patches for OpenSSH and prioritize ongoing update processes.
- Enhanced Access Control: Limit SSH access through network-based controls to minimize attack risks.
- Network Segmentation and Intrusion Detection: Divide networks to restrict unauthorized access and lateral movements within critical environments, and deploy systems to monitor and alert on unusual activities indicative of exploitation attempts.
- Implementing a Temporary Workaround: If an upgrade isn’t possible right away, set the LoginGraceTime parameter to 0 in the OpenSSH configuration file. This prevents unauthenticated sessions from staying open and being exploited. Note, however, this may lead to denial of service if all connection slots are occupied.
- Enhancing Security with Seccomp: By restricting sshd’s system calls, reducing attack surface and preventing exploitation of unsafe functions like syslog, thus constraining arbitrary code execution in case of vulnerabilities.
RELIANOID Load Balancer: Commitment to Security
All versions of the RELIANOID Load Balancer already have the updated packages in the repository, reflecting our commitment to providing the most secure and reliable load balancer. Ensure to have the latest updates applied in your load balancers and servers.
Stay vigilant and ensure your systems are patched and protected against this significant security threat. Contact with our security experts to know more about this vulnerability.
Related Blogs
