regreSSHion: Remote Unauthenticated Code Execution Vulnerability In OpenSSH Server

The Qualys Threat Research Unit (TRU) has discovered a Remote Unauthenticated Code Execution (RCE) vulnerability in OpenSSH’s server (sshd) in glibc-based Linux systems. CVE assigned to this vulnerability is CVE-2024-6387.

The vulnerability, which is a signal handler race condition in OpenSSH’s server (sshd), allows unauthenticated remote code execution (RCE) as root on glibc-based Linux systems; that presents a significant security risk. This race condition affects sshd in its default configuration.

Based on searches using Censys and Shodan, we have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet. Anonymized data from Qualys CSAM 3.0 with External Attack Surface Management data reveals that approximately 700,000 external internet-facing instances are vulnerable. This accounts for 31% of all internet-facing instances with OpenSSH in our global customer base. Interestingly, over 0.14% of vulnerable internet-facing instances with OpenSSH service have an End-Of-Life/End-Of-Support version of OpenSSH running.

In our security analysis, we identified that this vulnerability is a regression of the previously patched vulnerability CVE-2006-5051, which was reported in 2006. A regression in this context means that a flaw, once fixed, has reappeared in a subsequent software release, typically due to changes or updates that inadvertently reintroduce the issue. This incident highlights the crucial role of thorough regression testing to prevent the reintroduction of known vulnerabilities into the environment. This regression was introduced in October 2020 (OpenSSH 8.5p1).

About OpenSSH: Securing Enterprise Communications and Infrastructure

OpenSSH (Open Secure Shell) is a suite of secure networking utilities based on the Secure Shell (SSH) protocol, which is vital for secure communication over unsecured networks. It provides robust encryption to ensure privacy and secure file transfers, making it an essential tool for remote server management and secure data communication. Known for its extensive security and authentication features, OpenSSH supports various encryption technologies and is standard on multiple Unix-like systems, including macOS and Linux.

OpenSSH’s implementation serves as a critical tool for secure communication. Its enterprise value lies in its scalability and the ability to enforce robust access controls and secure automated processes across various environments. This includes everything from automated backups and batch processing to complex DevOps practices, which involve the secure handling of sensitive data across multiple systems and locations. Its continued development and widespread adoption highlight its importance in maintaining the confidentiality and integrity of network communications worldwide.

OpenSSH stands as a benchmark in software security, exemplifying a robust defense-in-depth approach. Despite the recent vulnerability, its overall track record remains exceptionally strong, serving as both a model and an inspiration in the field.

Affected OpenSSH versions:

• OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.

• Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.

• The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.

Potential Impact of regreSSHion

This vulnerability, if exploited, could lead to full system compromise where an attacker can execute arbitrary code with the highest privileges, resulting in a complete system takeover, installation of malware, data manipulation, and the creation of backdoors for persistent access. It could facilitate network propagation, allowing attackers to use a compromised system as a foothold to traverse and exploit other vulnerable systems within the organization.

Moreover, gaining root access would enable attackers to bypass critical security mechanisms such as firewalls, intrusion detection systems, and logging mechanisms, further obscuring their activities. This could also result in significant data breaches and leakage, giving attackers access to all data stored on the system, including sensitive or proprietary information that could be stolen or publicly disclosed.

This vulnerability is challenging to exploit due to its remote race condition nature, requiring multiple attempts for a successful attack. This can cause memory corruption and necessitate overcoming Address Space Layout Randomization (ASLR). Advancements in deep learning may significantly increase the exploitation rate, potentially providing attackers with a substantial advantage in leveraging such security flaws.

Addressing the regreSSHion vulnerability in OpenSSH, which enables remote code execution on Linux systems, demands a focused and layered security approach. Here are concise steps and strategic recommendations for enterprises to safeguard against this significant threat:

1. Patch Management: Quickly apply available patches for OpenSSH and prioritize ongoing update processes.
2. Enhanced Access Control: Limit SSH access through network-based controls to minimize the attack risks.
3. 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.

Technical Details

You can find the technical details of this vulnerability at:  

https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt

Qualys QID Coverage

Qualys is releasing the QIDs in the table below as they become available, starting with vulnsigs version VULNSIGS-2.6.83-4 and in Linux Cloud Agent manifest version LX_MANIFEST-2.6.83.4-5

Please check the Qualys Vulnerability Knowledgebase for the full list of coverage for this vulnerability.

Discover Vulnerable Assets Using Qualys CyberSecurity Asset Management (CSAM)

The initial and crucial step in managing this critical vulnerability and mitigating associated risks involves pinpointing all assets susceptible to this specific issue. Use CSAM 3.0 with External Attack Surface Management to identify your organization’s internet-facing instances that have vulnerable versions of OpenSSH or are at their End of Life (EOL) or End of Support (EOS).

Free Trial

Try CSAM 3.0 at no cost for 30 days

In the following example, we aim to identify all assets running the OpenSSH:

software:(name:"openssh" and version4.4 and lifecycle.stage: `EOL/EOS`) or software:(name:"openssh" and version9.8 and version>=8.5 and lifecycle.stage: `EOL/EOS`)

software:(name:"openssh" and version4.4) or software:(name:"openssh" and version9.8 and version>=8.5)

Enhance Your Security Posture with Qualys Vulnerability Management, Detection, and Response (VMDR)

Qualys VMDR offers comprehensive coverage and visibility into vulnerabilities, empowering organizations to rapidly respond to, prioritize, and mitigate the associated risks. Additionally, Qualys customers can leverage Qualys Patch Management to remediate these vulnerabilities effectively.

Leverage the power of Qualys VMDR alongside TruRisk and the Qualys Query Language (QQL) to efficiently identify and prioritize vulnerable assets, effectively addressing the vulnerabilities highlighted above.

Free Trial

Try Qualys VMDR at no cost for 30 days

Use this QQL statement:

vulnerabilities.vulnerability.cveIds:CVE-2024-6387

With the Qualys Unified Dashboard, you can track the vulnerability exposure within your organization and view your impacted hosts, their status, distribution across environments, and overall management in real time, allowing you to see your mean time to remediation (MTTR).

To make it easier for customers to track and manage regreSSHion vulnerability in their subscriptions, we have created the Manage regreSSHion dashboard, which you can download and import into your subscription.

Automatically Patch “regreSSHion” vulnerability With Qualys Patch Management

We expect vendors to release patches for this vulnerability shortly. Qualys Patch Management can  automatically deploy those patches to vulnerable assets, when available.

Customers can use the “patch now” button found to the right of the vulnerability to add regreSSHion to a patch job. Once patches are released, Qualys will find the relevant patches for this vulnerability and automatically add those patches to a patch job. This will allow customers to deploy those patches to vulnerable devices, all from the Qualys Cloud Platform.

Free Trial

Qualys Patch Management No-Cost 45-Day Trial

Frequently Asked Questions (FAQs)

Will the Qualys Research Team publish exploit code or include proof-of-concept code for this vulnerability?

No, as part of our commitment to responsible disclosure and maintaining high-security standards, we will not publish exploit codes. Given the complexity of this vulnerability, it is crucial to allow organizations to apply patches effectively without the immediate pressure of public exploits.

Are there any mitigations for this vulnerability?

If sshd can’t be updated or recompiled, set LoginGraceTime to 0 in the config file. This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk.

Is this vulnerability remotely exploitable?

Yes, this vulnerability can be exploited remotely and allows unauthenticated remote code execution (RCE) as root, posing a significant security risk.

Why is the vulnerability named “regreSSHion”?

This is a pun/reference to this being a regression bug affecting OpenSSH.

Should organizations patch these vulnerabilities urgently?

Yes, we would encourage organizations to patch this vulnerability urgently, especially on their internet-facing assets.

How will the new security fix be implemented for different versions?

This fix is part of a major update, making it challenging to backport. Consequently, users will have two update options: upgrading to the latest version released on Monday, July 1st (9.8p1) or applying a fix to older versions as outlined in the advisory, which is the approach most vendors will take.

Does this vulnerability affect macOS or Windows?

While it is likely that the vulnerability exists in both macOS and Windows, its exploitability on these platforms remains uncertain. Further analysis is required to determine the specific impact.

How can users identify exploitation attempts of this vulnerability?

Exploitation attempts for this vulnerability can be identified by seeing many many lines of “Timeout before authentication” in the logs.

What is the exposure to Qualys infrastructure?

The Qualys security team has taken immediate steps to protect our corporate infrastructure and products from any impact regarding the exploitation of this vulnerability. At this time, we have not experienced any negative impacts or detected any exploitation attempts. In addition, the Qualys security team has implemented enhanced monitoring and response plans to detect and respond to future exploit attempts. Emergency patching procedures have been initiated to fully remediate the vulnerability. To further help the broader security community, we are sharing our detection logic (see FAQ: “How to identify exploitation attempts of this vulnerability?”) to help customers respond should attacks occur before patching and mitigation efforts are completed.

How can users identify systems vulnerable to the OpenSSH regreSSHion vulnerability?

Users can determine if their systems are vulnerable by verifying the version of the OpenSSH server installed. Systems running affected versions should be considered at risk and prioritized for updates.

Under what circumstances might QID 42046 fail to report accurately?

Accurate detection with QID 42046 requires root privileges, as the command used only runs with root access.

Why is a QID categorized as a confirmed or potential vulnerability?

A QID is reported as confirmed in authenticated scan results because these scans can access detailed information that verifies the vulnerability more reliably. On the other hand, remote unauthenticated scans categorize a QID as potential because they primarily depend on the information presented by the OpenSSH service banner. This banner might display a partial version of details, leading to less definitive conclusions about the presence of a vulnerability.

When will the Qualys Detection Score (QDS) be updated?

As the vulnerability begins to trend across various threat intelligence sources, our QDS will utilize these intelligent feeds for dynamic updates. We expect its effectiveness to reach a score of 90 or above.