In the modern minefield that is cyber risk and vulnerability management, the discovery of CVE-2024-3094 serves as a stark reminder of the vulnerabilities that lurk within the supply chains of business-critical applications. This vulnerability, found within the Linux xz compression library, showcases not only the complexities of modern software dependencies but also the persistent and evolving threats of supply chain attacks. Furthermore, the xz vulnerability reveals how the overlooked components of our software infrastructure can become the Achilles' heel in cybersecurity, providing opportunities for attackers to exploit critical systems. In today’s blog, we dive into the accidental discovery of this vulnerability, the challenges of detecting such threats with traditional cybersecurity tools, the widespread practice of code reuse, and the critical role of understanding software components to fortify defenses against supply chain attacks.

The Accidental Discovery: CVE-2024-3094 Unveiled

As most of us know now, CVE-2024-3094 was not discovered through a systematic security testing or planned code audit. It was uncovered almost by accident, when a developer at Microsoft noticed an unusual high CPU process usage after integrating an xz update, and had the initiative and drive (and let’s face it – the time) to go digging deeper. The Linux xz library - a tool that most developers would consider mundane – was purposefully obfuscated to avoid simple code review or other traditional discovery. It had the potential to provide attackers with unprecedented access to exploit a security specific application (in this case sshd) that we trust to increase the deployment security functions to a significant degree.

The potential impact, had this vulnerability not been unearthed and had actually made it to production RHEL systems, might have been catastrophic, compromising sensitive data across countless systems. This incident underscores the ever-present danger in the software we often take for granted and highlights the importance of continuous vigilance in cybersecurity practices. It also serves as a reminder that even the most seemingly benign pieces of software can harbor risks, and it emphasizes the importance of maintaining consistent and comprehensive vigilance in our cybersecurity efforts, and the need for truly understanding the risk in our software and products.

The reality is – it’s a near certainty that more of these attacks exist. We just haven’t found them yet. Even more of a certainty that more are to come. AI code analysis and writing will make library attacks easier to find and easier to exploit.

The Limitations of Antivirus and Code Scanning Tools

One of the more disconcerting revelations from this incident is the stark inefficacy of traditional antivirus and code scanning tools in detecting this type of supply chain attack. These tools, designed to sniff out known patterns of malware and vulnerabilities, falter when faced with novel or intricately embedded malicious code. Even in programs with high security maturity, supply chain attacks can quickly undo secure coding efforts. This limitation not only emphasizes the adaptability of cyber threats but also should compel us to reconsider our reliance on these tools as comprehensive solutions for cybersecurity.

In this case, we should count ourselves very lucky that the malicious code author hadn’t considered system performance in how the exploit was written. Bottom line, to defeat a similar threat that had been released into the wild at a large scale would require us identifying and cataloging risk in components through tools like SBOM analysis to aid in discovery. Many months of searching for log4j taught us this, but we’re behind on making this approach a reality.

The Double-Edged Sword of Code Reuse

The practice of reusing code is a double-edged sword. On one hand, it significantly accelerates development cycles, enabling rapid innovation and deployment. On the other, it introduces a latent risk, as a single vulnerability in a widely used component can lead to widespread compromises. CVE-2024-3094 is a prime example of this problem. And let’s be real – without code reuse, software would never recover the ability to advance at a rapid pace. The incident brings to light the critical need for due diligence in the adoption and maintenance of third-party code within our projects. I believe CISA’s focus on SBOMs as a tool to understand and track risk, combined with cyber informed engineering (software and hardware) are the only way defenders maintain the upper hand in security battles.

Safeguarding Against Supply Chain Threats: The Role of SBOMs

As we learn how to mitigate supply chain threats, understanding the software components that comprise our applications emerges as a critical strategy. This understanding is facilitated by Software Bill of Materials (SBOMs), comprehensive inventories that detail every ingredient in our software concoctions. SBOMs serve not just as a tool for transparency but as a cornerstone of security strategies, enabling teams to quickly identify and respond to vulnerabilities within their applications’ DNA. They do this by mapping and providing a searchable reference for what sub-components are present in an application. With this information, when we find a vulnerable component, the discovery path for where this risk lives in our environment (if at all) is much quicker, much more conclusive, and will allow us to focus on the remediation rather than the search (detect). The role of SBOMs in combating threats like CVE-2024-3094 cannot be overstated - I believe they will prove to be key for organizations to preemptively bolster their defenses against and quickly respond to supply chain attacks as they emerge.

Conclusion: Eternal Vigilance is the Price of Security

The discovery of CVE-2024-3094 within the Linux xz library serves as a wakeup call of the dependencies and vulnerabilities inherent in our digital ecosystems. Systems that we know and trust to provide secure methods can be derailed by unrelated third-party code. The incident underscores the critical need for Collaborative vigilance in the community, Comprehensive understanding of our software compositions and risk, and a Conclusive response in evolving and integrating component risk security practices. Fortress Information Security is leading critical infrastructure partnerships in not just documenting third party component threat through SBOMs, but operationally building this intelligence into cyber development and vulnerability management programs.