Guidance on the Critical OpenSSH Vulnerability regreSSHion
Executive summary
CVE-2024-6387 is a critical remote code execution (RCE) vulnerability in OpenSSH that stems from a regression of a CVE from 2006.
Exploitation requires winning a race condition, and could take hours or even weeks to successfully exploit.
The recommended course of action is patching to an unaffected version of the OpenSSH server on glibc-based Linux systems. For circumstances in which that is not possible, we’ve included other mitigation options to reduce potential impact.
We also provide an osquery to detect vulnerable versions of OpenSSH.
OpenSSH vulnerability background and technical analysis
A new critical vulnerability (CVE-2024-6387) in OpenSSH was recently discovered by the Qualys Threat Research Unit that could lead to unauthenticated RCE. On July 1, 2024, they released their findings about the regression of the vulnerability CVE-2006-5051, which was patched in 2006 and reappeared in 2021.
The root cause of the CVE is a race condition caused by unsafe handling of signals when user authentication times out. Upon timeout, a SIGALRM signal is generated, which causes an interrupt to a thread that is executing a heap management routine. If the signal handler itself calls the heap management routine, it could cause unexpected behavior and, in this case, execute arbitrary code.
Currently, there is a public proof of concept (PoC) that exploits this vulnerability, making it a known exploited vulnerability (This PoC is offered by a third party not affiliated with Akamai, so please perform your own due diligence before attempting any interaction with the code). Despite its severity, the PoC highlights some limitations for successful exploitation. One of the main limitations is the time it takes to exploit — on some systems, it could take several hours; on others, it could take up to a week. Other limitations include being subject to the operating system’s distribution and the OpenSSH server's version and configuration.
Who’s vulnerable?
The vulnerability affects many versions of OpenSSH — including most Linux distributions, as they ship with OpenSSH by default.
As the root cause for the vulnerability is a regression in OpenSSH’s code, very old versions of OpenSSH server are affected by the original CVE, and newer versions (before the regression) are not affected.
As of this article’s publication date, the known OpenSSH versions affected by this vulnerability are as follows:
The old version of the vulnerability (CVE-2006-5051) is affecting OpenSSH versions earlier than OpenSSH 4.4/4.4p1 (2006-09-27) [unless they are patched for CVE-2006-5051 and CVE-2008-4109]
The regression of the vulnerability was introduced in version OpenSSH 8.5/8.5p1 (2021-03-03)
OpenSSH maintainers have fixed the vulnerability within version OpenSSH 9.8/9.8p1 (2024-07-01)
One way you can search for affected servers is by using the following Insight query:
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
From our observations, 75% of networks had some machines with a vulnerable version of OpenSSH, and, on average, approximately 35% of machines in a given network were vulnerable. On the bright side, in our monitored environments, we've yet to see a machine with an SSH port open to the internet arbitrarily. Yet a quick search on Shodan does show more than 6 million accessible machines with a vulnerable version (Figure).
Shodan report from July 2, 2024, for vulnerable machines open to the internet
Potential impact
As the vulnerability affects OpenSSH by default, the potential impact is huge — it affects most Linux distributions, especially newer versions due to the regression.
However, there are three caveats that reduce the need for total panic:
The current PoC is only for x86 machines, as exploitation on amd64 machines (which are the standard today) is exponentially more complex because of stronger memory protections.
It is currently believed that successful exploitation requires a long time and multiple connections to trigger. As such, it should trigger most brute-force attack detectors.
Because of the two caveats above, this attack appears to be better suited as an initial access vector from the internet. Part of the impact can be mitigated by using proper segmentation for Internet SSH connections, and for traffic from machines that need to have internet-facing SSH interfaces (like jump boxes).
Mitigation
Patching
The most obvious course of action is to patch OpenSSH to the updated, not vulnerable version. However, since OpenSSH usually comes bundled with Linux distributions, patching depends on the vendor’s release of a patch, which can take additional time and tests.
Network administrators can use the osquery supplied in this blog post to detect their vulnerable assets and track them over time. Akamai Guardicore Segmentation customers can also use scheduled queries for that purpose, and then label their asset based on the query results.
Segmentation
As we noted above, this CVE exploitation is most likely suited for initial breach into networks, as successful exploitation can take hours if not days. It is therefore crucial to map all instances of internet OpenSSH interfaces, and close or restrict access to them.
In cases where arbitrary SSH access from the internet is required, we recommend applying network segmentation on those machines to restrict their access to the internal network and limit the blast radius in case of successful exploitation and breach.
Threat alert sensitivity
Since patches are not necessarily available yet, it may be prudent to increase your alert sensitivity on the workloads that could be potentially vulnerable and unpatched. That way, even if the vulnerability is exploited undetected, you may still have some awareness of its aftereffects. In particular, we recommend sensitivity to brute-force attempts, as that is how exploitation would most likely look.
Increasing alert sensitivity, however, will also increase alert fatigue. As a result, we also recommend adjusting the alert sensitivity according to the affected workload’s importance to the network or its impact.
Summary
In this blog post, we reviewed the available information about the regreSSHion critical vulnerability in OpenSSH, which was patched and disclosed recently.
For defenders, the critical move is to determine the vulnerability of the workloads in their network. We’ve attempted to help by providing an osquery to detect vulnerable versions of OpenSSH. We’ve also discussed what to do to mitigate some of the risk (i.e., adjust your threat alert sensitivity) when patching is unavailable.
This blog post provides an overview of our current understanding and our recommendations given the information available. Our review is ongoing and any information herein is subject to change. You can also visit our X account for real-time updates.