Earlier this week an important vulnerability was published. This vulnerability titled ‘OpenSSH: Possible Remote Code Execution Due To A Race Condition In Signal Handling’ has been assigned CVE-2024-6387.
In this post you learn what this vulnerability is, understand if your product might be affected, and possible resolutions.
Let’s start with the vulnerability’s main data:
Title: OpenSSH: Possible Remote Code Execution Due To A Race Condition In Signal Handling
CVE: CVE-2024-6387
CWE: CWE-364: Signal Handler Race Condition
Published: 2024-07-01
Affected Components: OpenSSH 8.5p1 to 9.7p1
Severity: 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)
Systems: glibc-based Linux systems
Impact: Root privileges
Resolution: Patch available (OpenSSH 9.8p1)
Description of Vulnerability CVE-2024-6387
OpenSSH is a large suite of secure networking connectivity tools based on the Secure Shell (SSH) protocol, used to secure network communications and to enable remote server management. In a client-server communication over an unsecured network, OpenSSH can prevent eavesdropping, connection hijacking, and other attacks, by establishing a secure communication channel through traffic encryption.
Qualys Security Advisory Team discovered a vulnerability in OpenSSH's server (sshd), identified by CVE-2024-6387, that could be used by a remote attacker to cause a denial of service (crash), or to bypass authentication and remotely access systems with root privileges.
When OpenSSH's server (sshd) handles the SIGALRM signal, the SIGALRM handler calls functions that are not async-signal-safe, such as syslog(). This can create a race condition where the signal handler can interrupt critical sections of code, potentially leaving the system in an inconsistent state. If a client does not authenticate within seconds (LoginGraceTime), then sshd's SIGALRM handler is called asynchronously.
An unauthenticated remote attacker may be able to remotely exploit this vulnerability by failing to authenticate within a set time period (120 by default, 600 in old OpenSSH versions).
In order to trigger this race condition, the CVE-2024-6387 proof of concept exploit, implements a complex exploitation process that involves several steps, primarily focusing on sending a sequence of malicious packets to the vulnerable OpenSSH server.
Once the attacker has identified a target system running a vulnerable version of sshd, it creates and sends over the network a sequence of malicious packets specifically crafted to trigger the race condition in the packed handler and the consequent buffer overflow. In this way the attacker can overwrite critical memory regions and gain control over the execution flow, leading to remote code execution with root privileges.
The complexity of this process is due to the fact that it requires precise timing to hit the race condition window, and multiple attempts are typically required due to the nature of race conditions. According to the Qualys research, on average it takes about 10000 attempts to win the race condition, that means approximately 6-8 hours to obtain a remote root shell.
This vulnerability (CVE-2024-6387) is a regression of CVE-2006-5051 (patched in OpenSSH version 4.4p1) that was introduced in OpenSSH 8.5p1 (October 2020) when changes were made to the logging infrastructure. OpenSSH versions between 8.5p1 and 9.7p1 (inclusive) on glibc-based Linux systems are all affected by this vulnerability.
Since OpenSSH is present by default on nearly every Unix-like and Linux system, this vulnerability can fully compromise a huge number of embedded systems and network servers.
For more details refer to: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
Prompt identification and resolution of vulnerabilities are key to keeping your product secure. With Security Pattern's SBOM & Vulnerability Management Solution, The ARIANNA platform, you receive notifications if your product is affected by a new or existing vulnerability. All our customers have been notified about CVE-2024-6387 and advised of the resolution.
OpenSSH vulnerability CVE-2024-6367 reported on the ARIANNA Platform
Products affected by the vulnerability
Exploiting this vulnerability requires several conditions to be met. The first step is determining if the vulnerable component is present in the device.
OpenSSH versions lower than 4.4p1 are vulnerable to this signal handler race condition, if not patched against CVE-2006-5051, or not patched against CVE-2008-4109, which was an incorrect fix for CVE-2006-5051.
OpenSSH versions between 4.4p1 (included) and 8.5p1(excluded) are not vulnerable to this signal handler race condition.
OpenSSH versions between 8.5p1 (included) and 9.8p1 (excluded) are vulnerable again to this signal handler race condition.
If the vulnerable component is present, the system where the OpenSSH server is in execution needs to be evaluated. The exploit leverages specific behaviours of glibc's memory allocator, making it primarily effective on Linux systems:
At the moment successful exploitation has been demonstrated only on 32-bit Linux/glibc systems with ASLR (Address space layout randomization).
Exploitation on 64-bit systems could be possible but has not been demonstrated yet.
Exploitation on non-glibc systems is conceivable but has not been examined.
Systems that lack ASLR or users of downstream Linux distributions that have modified OpenSSH to disable per-connection ASLR re-randomisation may potentially have an easier path to exploitation.
OpenBSD is not vulnerable.
In case your system met one the condition above, and has a vulnerable version of sshd in execution, this does not necessarily mean yet that a malicious actor will be capable of exploiting the vulnerability.
As described in the previous paragraph, the attack complexity is high, meaning that successful attacks require a high level of skill and time.
In any case, apply a fix or mitigation as soon as possible, since the potential for remote code execution with root privileges makes this vulnerability a serious issue for all affected systems.
Resolution to the vulnerability
An official patch has been released to fix the vulnerability. If possible, update to OpenSSH version 9.8p1 or later. If updating is not directly possible, temporal mitigation strategies can be applied to limit system exposure.
One strategy is to limit SSH access to only necessary IP addresses and networks using firewall rules.
Another strategy is to adjust the sshd configuration to limit attackers effectiveness:
Vulnerability can be avoided by removing the timeout for authentication attempts (LoginGraceTime parameter set to 0). This makes the system safe from the vulnerability since the race condition can’t be triggered, but it makes sshd vulnerable to a denial of service (the exhaustion of the number of connections).
Vulnerability effectiveness can be reduced by lowering the number of allowed unauthenticated connections (MaxStartups parameter), and the number of unauthenticated connections from a single source IP (PerSourceMaxStartups parameter). The drawback of this configuration is that by setting the values of these parameters too low may also block legitimate users.
In both cases, to review suspicious activity, keep recent network traffic monitored and evaluate potential anomalies.
How Security Pattern can help
Security Pattern has developed the ARIANNA platform. ARIANNA is a product security management platform for connected devices and systems. Built upon the principles of a robust vulnerability management process, ARIANNA supports device manufacturers to identify, triage, address and report vulnerabilities.
The platform supports analyzing the product for vulnerabilities and will alert the manufacturers about newly identified or critical vulnerabilities. In addition, it supports mitigating and fixing the identified vulnerabilities.
Benefits of the ARIANNA platform
SBOM management: Creation of an accurate SBOM. Automated maintenance of your SBOM with every software update through APIs. Exporting of SBOM in industry-accepted formats such as CycloneDX and SPDX.
Identification of vulnerabilities: Continuous monitoring and reporting of vulnerabilities. SUM can provide more accurate results though improved vulnerability mapping, identifying false positives and automatically closing patched vulnerabilities.
Triaging of vulnerabilities: Automated pre-triage using our proprietary engine reduces the vulnerabilities that need to be analyzed to only 10-15% of the total number of identified vulnerabilities. In addition, ARIANNA provides all relevant information to assess vulnerabilities, such as available exploits, severity, and EPSS score.
Management of vulnerabilities: Effectively view the code of available mitigations and fixes.
Compliance: Satisfy requirements from standards and regulations in your industry such as FDA pre-market application, IEC 62443, ISO/SAE 21434, ETSI 303 645, RED, IEC TR 60601-4-5, UL2900 and MDR EU 2017/745.
Want to see the ARIANNA platform in action?
Comments