On July 1, 2024, researchers published technical details regarding a vulnerability, dubbed regreSSHion, affecting the OpenSSH server component, sshd. OpenSSH is an open-source version of the Secure Shell (SSH) tool. The sshd component is designed to listen for connections from any of the client applications.
The flaw, tracked as CVE-2024-6387, with a high severity rating of 8.1, is due to a signal handler race condition in sshd. The condition could allow a threat actor connected to the server via a forwarded agent socket to execute remote commands with the privileges of the user account hosting the OpenSSH agent.
OpenSSH addressed this security issue with the release of OpenSSH version 9.8 on July 1, 2024.
The versions reported to be affected are:
- OpenSSH servers on Linux from version 8.5p1 up to, but not including, 9.8p1
- Versions older than 4.4p1 unless patched for CVE-2006-5051 and CVE-2008-4109
The researchers who discovered this vulnerability determined it to be a regression of a previously patched vulnerability, tracked as CVE-2006-5051. Regression means that a previously fixed flaw was unintentionally reintroduced in a later software release, in this case, in October 2020 with the release of OpenSSH 8.5p1.
Multiple distributions using OpenSSH as a dependency are reported to be affected by this flaw, including SUSE, FreeBSD, Debian, Oracle Linux, Amazon Linux, Slackware Linux, and Ubuntu.
Since publishing technical details with a proof-of-concept (POC) implementation on GitHub, multiple sources reported active scanning for this flaw heightening the risk of exploitation of vulnerable systems.
Analysis
There are multiple limiting factors for the exploitation of this vulnerability.
- Researchers pointed out that the flaw is hard to exploit and requires multiple attempts to achieve the necessary memory corruption.
- The POC relies on distribution-specific conditions, and a threat actor would need to find a Linux distribution on the target system before exploitation.
- The current POC has only demonstrated that this vulnerability is exploitable under lab conditions on 32-bit Linux/glibc systems with ASLR.
- Exploitation on 64-bit systems is believed to be possible but has not been demonstrated so far.
- Researchers have not demonstrated exploitation on non-glibc systems yet, although it appears to be possible.
- Successful exploitation is reported to take from 6 to 8 hours of continuous login attempts, which would be easy to detect with any basic defense mechanism.
- This technique would be better suited for a very targeted attack by an advanced actor who would be able to switch their infrastructure continuously over an extended period to remain undetected.
With these limitations in mind, if exploited, this flaw could lead to full system compromise and enable a threat actor attacker to execute malicious code with the highest privileges.
Mitigation
Field Effect’s security intelligence team constantly monitors the cyber threat landscape for potential security threats. This research contributes to the timely deployment of signatures into Field Effect MDR to detect and mitigate the exploitation of potential vulnerabilities.
Field Effect MDR users were already notified if an affected version of OpenSSH was detected in their environment and are encouraged to review these AROs as quickly as possible via the Field Effect Portal.
We recommend that you update OpenSSH to the latest version as soon as possible, prioritizing publicly exposed instances. Consider limiting SSH access through network-based controls and ensuring that OpenSSH servers are not exposed to the internet unless necessary.
Rocky Linux suggested a temporary workaround for those unable to fix the vulnerability now. It involves setting LoginGraceTime to 0 in /etc/ssh/sshd_config, which makes sshd vulnerable to a denial of service (the exhaustion of all MaxStartups connections) but protects the vulnerable instance from this flaw.
If any products in your environment are using OpenSSH dependencies, we recommend investigating to verify the update status for the vulnerable product on the relevant vendor advisory page. If an update is currently available, install the latest version of the product as soon as possible. If any of the products that received this update are found, Field Effect clients will receive an additional ARO informing them of its presence.
Related Articles
