Menu
A critical vulnerability – CVE-2024-6387 – has been discovered in OpenSSH, a widely used suite of secure networking utilities. This flaw, stemming from a signal handler race condition, poses critical risks including potential unauthorised remote code execution (RCE). Affected versions include 8.5p1 up to, but not including, 9.8p1, impacting numerous major Linux distributions such as Red Hat, Debian, and Ubuntu.
OpenSSH (also known as OpenBSD Secure Shell) is a suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides a secure channel over an unsecured network in a client–server architecture.
The SSH protocol (aka Secure Shell) is used to establish secure and reliable communications between two hosts. OpenSSH supports different SSH authentication methods, which can be specified in AuthenticationMethods directive within the /etc/ssh/sshd_config configuration file. Options supported include the use of password authentication (password), public key authentication (publickey), and host-based authentication (hostbased). However, less commonly used alternatives are available including none, which can be used for access to password-less accounts when PermitEmptyPassword is enabled.
A signal handler race condition was found in OpenSSH’s server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd‘s SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). This race condition affects sshd in its default configuration.
This vulnerability is in fact a regression of CVE-2006-5051, which was reported in 2006 – although the flaw was fixed it has since reappeared in a subsequent software release, via a code change that inadvertently reintroduced the issue. This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit 752250c (“revised log infrastructure for OpenSSH”), which accidentally removed an “#ifdef DO_LOG_SAFE_IN_SIGHAND” from sigdie(), a function that is directly called by sshd‘s SIGALRM handler.
This seems to affect glibc-based Linux systems and not e.g. musl-based systems. Impacted products and operating systems are known to include at least the below:
(OpenBSD is NOT currently believed to be affected.)
On some systems there is the possibility of attackers achieving unauthorised remote code execution (RCE). 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.
However, the complexity to achieve that is very high and time consuming due to the need of winning a race condition. Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It’s likely that these attacks will be improved upon.
If the attacker doesn’t achieve a win of the race condition, then the most likely outcome is to have the sshd server crash, generating availability impact only.
NOTE: Anonymized data from security vendor data reveals that approximately 700,000 external internet-facing instances may be vulnerable at time of publication. This accounts for an estimated 31% of all internet-facing instances with OpenSSH. Exploit code is available publicly in the wild via sites such as GitHub already. Prioritisation should be given to remediation in any impacted environment.
Update to the latest version. After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections on some systems. When upgrading remote hosts, please make sure to restart the sshd service using systemctl try-restart sshd or appropriate system-specific command directly after upgrading.
NOTE: Remediation of this vulnerability by patching to a specific version indicated may not be sufficient to secure the product against further vulnerabilities discovered in later versions, subsequent to the publication of this guidance. Unless contra-indicated, customers are therefore advised to always upgrade to the latest version of the product available.
NOTE: Caution should always be taken in applying any temporary mitigations listed. Mitigations are only recommended in cases where patches to remediate the vulnerability are not available, or cannot safely be applied to a given environment immediately. A given mitigation may not in all cases be recommended officially by the application vendor. The viability of any given temporary mitigation measure may vary, depending on server platform and existing configuration. Mitigations listed may incompletely remediate any given vulnerability. Configuration changes to implement listed mitigations may impact/disrupt required functionality within a given customer application. Care should therefore be taken to carefully analyse any listed mitigations for appropriateness to a given environment. Customers are advised to test any configuration changes prior to their being introduced into a production environment.
As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please contact us: info@appcheck-ng.com
For more information on this vulnerability or to search more vulnerabilities head to our Known Vulnerability Database: detections.appcheck-ng.com/cve-2024-3400
Further references for this issue are available from https://nvd.nist.gov/vuln/detail/CVE-2024-6387
AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).
No software to download or install.
Contact us or call us 0113 887 8380
