Vulnerability Management RegreSSHion and Supply Chain Risk Amplification Through Package Dependencies

Discover the RegreSSHion (CVE-2024-6387) vulnerability, a reintroduced unauthenticated RCE in OpenSSH, and its impact on software supply chains through package dependencies.

 

Background

RegreSSHion (CVE-2024-6387) is an unauthenticated remote code execution (RCE) vulnerability in certain versions of the OpenSSH server daemon involving a race condition that can be triggered to gain root execution privileges. It is a reintroduced vulnerability, or regression, of the previously-patched CVE-2006-5051.

A Relatively Quiet RegreSSHion

While the severity and impact of RegreSSHion is as bad as it gets (see the CVSS3.1 assessment’s Base Score Exploitability Metrics), the overall Exploitability Score is relatively low at only 2.2 resulting in a Base Score of 8.1[3]. This may be due to the complexity of the attack’s Proof of Concept (PoC) exploit, which can require around 10,000 tries on average to win the race condition[2], per the Qualys Threat Research Unit[1]. The downside of such a low exploitability score is that the resulting Base Score of 8.1 may fly under the radar for a number of Vulnerability Management teams, which may cause an otherwise serious vulnerability to fall below threat mitigation prioritization thresholds.

Due to the high impact, low exploitability rating of the initial RegreSSHion PoC and its potential to fall below common prioritization thresholds for Cyber Risk Management divisions, the Research group at NetRise took a cursory look at RegreSSHion and its prevalence in popular Package Manager dependency chains.

Vulnerable Versions and the Software Supply Chain

According to the initial advisory[2], there are two vulnerable version ranges of the underlying OpenSSH implementation: 

  1. OpenSSH before 4.4p1 where instances are not backport-patched against both CVE-2006-5051 and CVE-2008-4109

  2. OpenSSH from 8.5p1 (inclusive) to 9.8p1 (non-inclusive)

While there may be a number of vulnerable SSH server instances in the older < 4.4p1 range[4], the more recent 8.5p1 <= OpenSSH < 9.8p1 version range is arguably more relevant from a Supply Chain perspective. This second range of vulnerable OpenSSH releases spans March 2021 to March 2024 and is more likely to be included in a package manager’s latest dependencies, either as a direct dependency or transitive dependency for other packages.

Prevalence of OpenSSH as a Dependency in the Debian Package Manager Ecosystem

Package dependency hierarchies can be modeled as a tree or graph to show whether subsequent packages are direct dependencies or transitive dependencies of a parent package. Additionally, we also look at pinned version dependencies, where a specific package release version range is required, versus unpinned version dependencies where any available version of the required package will do. In order to detect dependency chains where a vulnerable version may be present regardless of local package manager configuration, we’ll look primarily at pinned version dependencies.

The simplest scenario, and the one most commonly checked for by package dependency tools, is looking at the direct dependencies of a parent package or application. For this type of dependency analysis to be effective at detecting versions of OpenSSH vulnerable to RegreSSHion, said applications and packages would have to require the openssh-server package directly.


OpenSSH Server as a Direct Dependency

OpenSSH Server as a Direct Dependency Diagram

Out of the data pulled from 289,361 unique Debian package versions, 945 package versions contained openssh-server as a direct dependency. Of these direct dependency references, there were 875 unpinned version dependencies and 70 pinned version dependencies. 71.4% (50) of the pinned version dependencies fell within the version ranges vulnerable to RegreSSHion.

This might appear like a shockingly high number at first glance, but most of these package versions are from parent SSH metapackages or OpenSSH test packages. In order to get a real sense of the breadth of impact on third-party packages, we’ll need to look at transitive dependencies as well.

Previously we were only interested in packages and applications with openssh-server as a direct dependency since this is the package with the implementation vulnerable to RegreSSHion, but now we have to build out a list of packages that are likely to include openssh-server as a transitive dependency as well.

To include transitive dependencies at a depth of N=1, the searched package list is expanded to include all of the direct parent dependencies as well as all metapackages that may contain an openssh-server dependency. This results in the following (not all inclusive) subset of packages and metapackages: openssh, openssh-server, openssh-tests, ssh, ssh-server.

OpenSSH Server as a Transitive Dependency

OpenSSH Server as a Transitive Dependency

Out of the data pulled from 289,361 unique Debian package versions, 1,537 parent package versions contained openssh-server as a transitive dependency at a depth of n=1. Of these depth n=1 transitive dependency references, there were 1,467 unpinned version dependencies and the original 70 pinned version dependencies. This is an additional 592 dependencies when compared to original direct dependency analysis. This type of transitive dependency analysis can be expanded to further dependency depths. Taking each of these additional n=1 depth package versions as target dependencies and then performing a depth n=2 analysis, and so on, would result in an even more holistic view of the total number of impacted dependency chains.

While we primarily took a look at the breadth of impact for pinned versions of direct dependencies of Debian packages (since they have verifiable versions regardless of local package manager configuration), it is worth noting that unpinned version dependencies may also be impacted in the event of outdated package mirrors or local package manager misconfigurations. For this reason, it is important to make sure that package repositories are up to date as often as reasonably possible.

An Evolving Threat

Research findings and National Vulnerability Database entries are ever-evolving. A patch may be found inadequate at a later date or the code implementing the patch may regress, reintroducing a vulnerability. Additionally, exploit PoC code may become more mature over time, leading to increased exploitability risk by means of less-restrictive environmental constraints or user interaction requirements.

In the case of RegreSSHion, unpatched instances of OpenSSH Server are likely to be around for a while in the form of transitive package dependencies, especially due to its relatively moderate CVSS Base Severity Score. The initial security advisory and subsequent threat briefs[2][4] call out the complexity of demonstrating a working exploit in the existing PoC’s state, requiring up to days of server request exhaustion just to achieve one root shell[2]. As more independent security researchers investigate the technical aspects of this vulnerability, this ease of exploitability is likely to change.

The only way to get a true representation of a component’s risk at a given point in time is to continuously monitor for updates to vulnerability listings and advisories. Detecting if and when new exploit PoC code is released for a vulnerability listing as well as whether known threat actors are using said PoC in the wild is important for managing real threats in a product security landscape, especially when it comes to transitive dependencies that may reside N levels deep in a third-party package dependency chain.

Monitoring Software Supply Chain Risk with the NetRise Platform

Software supply chains and the risks associated with them are constantly changing. Not only do organizations need to be able to maintain an accurate view of their software supply chain but they also need to be able to stay up-to-date with the latest vulnerability and exploit intelligence which is no small order for security resources that are already stretched thin.

The NetRise Platform allows organizations to gain visibility into their software supply chain and continuously monitor it for new vulnerabilities and new exploit intelligence. The NetRise Platform also helps organizations prioritize which vulnerabilities to focus on, further increasing the effectiveness of any security team.

Schedule a demo today to learn how the NetRise Platform can help you solve your software supply chain problems.

References:

[1] Qualys Threat Research Unit Blog - regreSSHion

[2] Qualys Security Advisory (CVE-2024-6387)

[3] CVSS Version 3.1 Assessment - CVE-2024-6387

[4] Palo Alto Unit 42 Threat Brief - CVE-2024-6387