Introduction
On July 1, 2024, the Qualys Threat Research Unit (TRU) revealed information about a vulnerability discovered in OpenSSH [1] – one of the most popular and secure services for remote server access, mainly used in Linux systems.
The vulnerability has been assigned the CVE identifier CVE-2024-6387, and it is characterised in the NVD database as follows:
A security regression (CVE-2006-5051) was discovered in OpenSSH’s server (sshd). There is a race condition which can lead sshd to handle some signals in an unsafe manner. An unauthenticated, remote attacker may be able to trigger it by failing to authenticate within a set time period. [2]
The National Vulnerability Database (NVD) is a comprehensive repository of information about known cybersecurity vulnerabilities, including details on their severity, impact, and fixes. Common Vulnerabilities and Exposures (CVE) is a system that provides unique identifiers for publicly known vulnerabilities and exposures.
One of the most intriguing aspects of this vulnerability is that it was present in OpenSSH and was even assigned CVE-2006-5051 a long time ago. However, due to a programming error when OpenSSH’s code was modified, the vulnerability reappeared starting in October 2020.
The vulnerability can be summarised as a signal handler race condition that allows unauthenticated remote code execution with root privileges. To better understand what this entails, we will break down this description into its fundamental components and explain each term in an accessible manner.
What is OpenSSH?
OpenSSH (Open Secure Shell) is a widely used open-source suite of tools designed to provide secure remote access and data transfer over unsecured networks. Developed as part of the OpenBSD project, OpenSSH offers a robust, encrypted protocol for secure communication between systems. The main tool for secure remote shell access is ssh, which allows users to log in and execute commands securely on remote machines. OpenSSH employs strong encryption and authentication mechanisms to protect data from eavesdropping and tampering. It supports various authentication methods, including password-based and key-based authentication and advanced features like port forwarding and secure tunnelling. In practice, the OpenSSH server is the most commonly used option for establishing connections with Linux systems.
Who is root?
The root is the most privileged user on the Linux system. He has full and unrestricted access to the entire system.
What is RCE?
Remote Code Execution (RCE) is a vulnerability that represents a critical security flaw that allows an attacker to execute arbitrary code on a remote system over a network. It can be said that this is the type of vulnerability that every hacker dreams about. Executing remote code can lead to many serious consequences. For example, hackers can access sensitive resources on the machine, install malware and backdoors (which will enable them to obtain persistence and reconnect to the attacked system) and disrupt or affect the services running on the system. In extreme cases, remote code execution allows hackers to take complete control of the attacked system.
What is the idea behind the signal handler race condition in OpenSSH?
Signal handlers are functions in a program that respond to signals, which are notifications sent to a process. A race condition happens when the timing of events leads to unexpected or incorrect behaviour. In signal handlers, this often involves problems due to asynchronous actions (things happening out of order). If both the signal handler and regular code access the same global variables or static data, and if the signal handler modifies them while the regular code is using them, it can cause issues like data corruption or crashes. Attackers might exploit these race conditions to corrupt the program’s state, potentially causing it to crash or allowing unauthorised code execution.
In OpenSSH, the signal handler race condition issue arises when a client does not authenticate within the LoginGraceTime period. The LoginGraceTime parameter specifies the time allowed for successful authentication to the SSH server. The longer the grace period, the longer the unauthenticated connections can last. [3] The default value of this parameter is 120 seconds. If this timeout is reached, SIGALRM handler is triggered asynchronously and calls functions that are unsafe for signal handlers, such as syslog(). In versions earlier than 4.4p1, an attacker could exploit the free() function used within syslog() during the signal handler. In versions from 8.5p1 to 9.7p1, both free() and malloc() functions are vulnerable to exploitation. The proof-of-concept from Qualys Threat Research Unit is based on using the public key data segment to send the exploit payload. If the exploitation is successful, the attacker enforces code execution that allows him to obtain the root shell. Because exploitation needs perfect timing, many attempts are statistically needed to succeed. For example, for OpenSSH on the 32-bit system, it took 10,000 guesses to hit a successful execution on average. [4] The Qualys Threat Research Unit is in the process of crafting and testing exploits on 64-bit systems. [5]
SIGALRM is a signal used in Unix-like operating systems to notify a process that a timer has expired. A process can catch this signal and handle it using a signal handler function. This function is executed when the signal is received. The functions mentioned in the text above are part of the C language: syslog() – this function is used to write log messages to a system log.malloc() – this function allocates (reserves) a block of memory for use.free() –this function is used to release memory that was previously allocated by the malloc() function.
Affected Versions
To summarise the information about vulnerable software [5]:
- OpenSSH < 4.4p1 is vulnerable,
- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable,
- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again.
However, remember that the theoretically vulnerable version might be patched. For example, the patch was introduced for different versions of OpenSSH for the Ubuntu operating system. [6, 3] Thus, the version of the OpenSSH is not an unambiguous indicator of the presence of vulnerabilities.
To check the version of the OpenSSH on your system, execute the following command in the terminal:
ssh -V
Note that Windows systems are not affected. Moreover, Alpine Linux and OpenBSD are probably not vulnerable to this attack. Red Hat Enterprise Linux 9 has the potential to be vulnerable, but other controls have stopped the path to exploitation. [4]
Remediations
To directly mitigate the CVE-2024-6387 vulnerability, you can perform the following actions:
- Update the OpenSSH to the latest available version or install the patched version.
- As a not-perfect workaround (if you can’t install an updated version of OpenSSH), set the LoginGraceTime parameter to 0 in /etc/ssh/sshd_config. This completely mitigates CVE-2024-6387. However, it makes the OpenSSH server vulnerable to a denial of service. [4]
You can also apply the following additional steps in order to generally mitigate the risks associated with the possibility of abusing the OpenSSH service:
- Firewall Rules – use firewalls to restrict access to the SSH service to trusted IP addresses only.
- Network Segmentation – isolate SSH servers on separate network segments or VLANs to reduce the risk of lateral movement within the network if a server is compromised.
- Harden SSH Configuration – disable root login over SSH, and use private-key authentication instead of password authentication.
- Monitor and Log Activity – enable and monitor SSH logs to detect suspicious activity or unauthorized access attempts. Regularly review logs for signs of potential compromise.
Let’s emphasize it again – the above additional steps are good practices to allow general hardening of OpenSSH server, but they do not directly mitigate the threat of the described regreSSHion vulnerability.
Key Takeaways
- The regreSSHion is a race condition vulnerability in the OpenSSH server that can allow an unauthenticated remote command execution as root.
- The vulnerability applies to some Linux systems. Windows systems are not affected.
- For now, the proof of concept for 32-bit Linux systems was presented. Exploiting 64-bit Linux systems is theoretically possible and the research is ongoing.
- Since vulnerability exploitation is very complicated, it is unlikely to occur in the wild in the near future. However, the potential impact is severe enough to take the proposed remediations seriously.
- For remediation, update the OpenSSH to the latest version.
Bibliography
[1] B. Jogi, “regreSSHion: Remote Unauthenticated Code Execution Vulnerability in OpenSSH server,” [Online]. Available: https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server#affected-openssh-versions.
[2] “NVD NIST,” [Online]. Available: https://nvd.nist.gov/vuln/detail/CVE-2024-6387.
[3] “Ensure SSH LoginGraceTime is set to one minute or less,” SecScan, [Online]. Available: https://secscan.acron.pl/centos7/5/2/14.
[4] “RegreSSHion exploit, CVE-2024-6387: A Write-Up,” Offsec Team, [Online]. Available: https://www.offsec.com/blog/regresshion-exploit-cve-2024-6387/.
[5] “regreSSHion: RCE in OpenSSH’s server, on glibc-based Linux systems (CVE-2024-6387),” Qualys Security Advisory, [Online]. Available: https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt.
[6] “CVE-2024-6387,” Ubuntu Security, [Online]. Available: https://ubuntu.com/security/CVE-2024-6387.