Unpacking libuv’s CVE-2024-24806: software dark matter will go under the radar (not in Chainguard Images, tho)

Editor's note: A previous version of this blog post incorrectly credited the reporter of this vulnerability, Arash Shakery. Our apologies for this error.

‍

On January 24, 2024 security research Arash Shakery discovered CVE-2024-24806, a vulnerability that exposes a security flaw in libuv versions post 1.45.x. The server-side request forgery (SSRF) flaw was found in the libuv package due to how the hostname_ascii variable is handled in uv_getaddrinfo and uv__idna_toascii. When the hostname exceeds 256 characters, it gets truncated without a terminating null byte allowing for an overflow. An SSRF — it’s now known — is not the only way to exploit said vulnerability. According to the CVE filed in the uv project, access to internal APIs is also possible “when deployed in an environment with multiple pods (e.g., Kubernetes), is vulnerable to the attack described above, potentially allowing unauthorized access to internal APIs.”

‍

As a result, attackers may be able to access internal APIs or, for websites that allow users to have customized subdomains like username.example.com pages, internal services that crawl or cache these user subdomains/pages can be exposed to SSRF attacks if a malicious user chooses a long vulnerable username. This issue could allow an attacker to craft payloads that resolve to unintended IP addresses, bypassing developer checks.

‍

This is big, scary and … dark.

‍

Dark matter creeps under SBOM and container’s radar

This vulnerability is quite tricky to spot by traditional methods. This is an example of a vulnerability that will be reported as a false negative (i.e will not be reported) because it’s part of what’s referred to as software dark matter. Software dark matter is untracked software components within containers, invisible to scanners or SBOMs tools. It is found in about 32% of popular open-source containers, according to our own research. We’ve covered in this blog the perils of software dark matter before. This "dark matter" makes it harder for analysis tools to detect vulnerabilities, posing significant security challenges.

‍

The nature of such vulnerabilities makes them particularly dangerous, as they can remain hidden within systems for extended periods, potentially allowing for undetected exploitation by malicious actors. This is exactly what happened with this vulnerability: it is likely going under the scanner’s radar because of the way it is bundled or vendored into popular packages. Certain ways of packaging software obfuscate, even if inadvertently, relevant information to scanners.

‍

When vulnerabilities are found within software dark matter and are part of extremely popular software projects (remember that libuv comes bundled in node.js, node.js being on of the most downloaded projects in any public image registry and certainly in ours https://images.chainguard.dev) the blast radius becomes enormous. Libuv is present in many projects. Notably, it's embedded within Node.js, Julia, or Neovim to name a few. Given its extensive application, a conservative estimate suggests that hundreds of thousands of developers globally rely on libuv.

Chainguard Images are not fooled by dark matter!

The way that traditionally container images are built doesn’t help surface these vulnerabilities either. We know from our own research that software dark matter is being reduced across the board. In fact, around thirty percent of the images found in popular public registries have less than one percent software dark matter. Some containers are therefore already building images with little to no software dark matter, although the practice appears to be far from widespread. And still these vulnerabilities will go unmarked in scanner reports.

This is precisely why Chainguard saw the need to build its own open source toolchain. With Wolfi we add and curate everything that goes into the packages. We follow the distroless philosophy of less is more: only what’s really needed to run, in this case node.js, will be added to the packages that are used to build the node.js image. With this approach, we considerably reduce the attack surface by removing unnecessary packages and binaries. In Chainguard’s Images there are fewer components that can be exploited by attackers.

‍

Also, with fewer components in the image, there are fewer items to scan for vulnerabilities and less complexity in managing software licenses. Chainguard Images make container image scanner reports easy to understand if only because there are so few vulnerabilities to report about (if any) but also because the scanner has to scan less software and less deps.

‍

And it trickles down to a securer infrastructure too! Since Chainguard Images do not include shells or other debugging tools, they encourage immutable infrastructure practices (like GitOps or declarative infrastructure states). While this can make debugging more challenging (Chainguard Images include a version of images with a package manager and a shell for admins), it also enforces an environment where changes are made through the CI/CD pipeline, enhancing security and consistency across environments.