Overview
By now, you have heard that on March 29th, malicious code was embedded in XZ Utils versions 5.6.0 and 5.6.1, which was assigned CVE-2024-3094. Red Hat issued an urgent advisory for users to cease using systems operating on Fedora’s development and experimental versions. This precautionary measure was taken after a backdoor was identified within the most recent versions of the XZ Utils data compression tools and libraries. Given that this compromised library is commonly utilized in Linux, its presence is more probable in container images than in users’ code.
The good news is that CVE-2024-3094 was likely detected before it could significantly impact downstream production, preventing widespread issues. Of course, as new information comes to light, stakeholders will have numerous inquiries regarding the backdoor’s nuances, whether similar occurrences occur, and what is being done to communicate resiliance.
In this blog post, we offer a streamlined guide that covers detecting the issue and presenting a succinct playbook for handling similar incidents in the future.
Background
The backdoor was discovered accidentally by Andres Freund, a PostgreSQL developer and a Microsoft software engineer. Freund was investigating peculiar activities, including unusually high CPU usage during SSH logins, on Debian sid installations.
CVE-2024-3094 is identified as a critical vulnerability resulting from malicious code discovered in the upstream tarballs of XZ, starting with version 5.6.0. This vulnerability involves a sophisticated method where the liblzma build process extracts a prebuilt object file from a disguised test file within the source code. This object file is then used to modify specific functions in the liblzma code. The complexity of the obfuscations and the modifications made to the liblzma library allows for unauthorized activities, such as bypassing SSH authentication under certain conditions in specific versions of certain systems (CVE) (wiz.io).
Interestingly, the GitHub account Jia Tan, which has been associated with the project for several years, had earned the trust of the xz-utils maintainers. During this period of established credibility, an attempt was made to introduce their backdoor into the official distributions of Linux operating systems.
A great breakdown can be found on linuxiac.com.
Building a Playbook
The XZ backdoor goes beyond the typical “event,” striking at the heart of trust within the open-source ecosystem and spotlighting the security of widely utilized software components. This backdoor underscores a critical risk point attackers could exploit, endangering vital systems. Today, where open-source software is integral to nearly every enterprise, the imperative for proactive security measures is clear.
To enhance trust in open-source software and manage the associated risks, enterprises are encouraged to actively support the maintenance of critical open-source projects on which they depend. This support can range from contributing code fixes to engaging in project security discussions, thereby improving the ecosystem’s overall health.
Regular audits of software dependencies allow organizations to identify and address vulnerabilities proactively rather than reacting to incidents after the fact. Moreover, it is vital to equip developers with the knowledge and tools to prioritize security, especially in choosing and managing dependencies. This involves not only writing secure code but also understanding how to assess the security posture of open-source components they integrate into their work.
Communicating Your Exposure and Building Resilience with OX
The XZ backdoor incident underscores the critical importance of continuous security practices throughout the development lifecycle.
By leveraging OX, customers can streamline their security protocols across the SDLC. This approach ensures peace of mind and equips you with the necessary data to confidently strategize your subsequent actions. For those not yet on board, OX provides a free trial. It offers an effortless, agentless, and API-based connection that can be deployed in under a minute.
The steps below can help in this case and be used in future scenarios.
- Log in and connect your environment’s source control, CI/CD, and artifact registry.
- The banner allows us to navigate to all issues with the vulnerability (Active Issues Screen) or all libraries with the vulnerability (SBOM Screen)
- The platform will automatically scan your connected environment from code to cloud.
- It will detect direct uses of XZ libraries and will alert the vulnerable ones.
OX’s container scanning functionality utilizes the capabilities of a Software Bill of Materials (SBOM) to detect vulnerable packages in your containerized applications. This feature enables you to accurately identify the presence of the XZ backdoor or any other security vulnerabilities within your deployments, facilitating quick and effective remediation measures. To get there.
- Click on the BOM icon screen.
- In the search bar, search for “xz.”
- It will find all direct and indirect xz utils libraries and show the version used.
Note: the stable versions of Linux distros were not affected. It’s mostly beta/dev branches of those OSs.
- In the image above, you can see the library and its details.
- The example shows that it is free from malicious code.
- You can easily show this to stakeholders.
Example 2 – Going Through the Active Issues Page
The detection below is on an image modified by OX to contain the vulnerability. This example highlights if we were impacted (though results are similar regardless of how you search). This feature does more than just spot dependencies; it extensively evaluates the health of every library in your codebase. The analysis looks into various elements crucial in determining the security level, including how often it’s maintained, the rigor of code review processes, the strength of branch protection policies, and other significant factors.
- Click on the Active Issues page.
- In the search bar, search for “XZ” or CVE-2024-3094 (the example below shows XZ)
- In the Active Issues page, we have a severity factor called “malicious code in dependency” with a link to the RedHat advisory.
- In the Active Issues page, we report on the offending OS (modified by us). As you can see, the results are not good, and AppOXalypse.
- In the Active Issues page, we have upgraded the severity of the issue to “AppOXalypse,” our super rare severity, which means fix NOW!
- In this case, you can send an email, Slack, or Jira from the system. You can do this from the Active Issues screen (above) or set up a no-code workflow. This enables you to easily communicate with your dev team and have them prioritize the fix.
- You can also highlight your next steps and why to other stakeholders.
On-going tracking and community collaboration
This incident has fueled discussions about open-source software security and human teams’ critical role in detection efforts. CVE-2024-3094 was likely detected before it could significantly impact downstream production, preventing widespread issues. However, this vulnerable library was used in Linux; it is more likely to be found in container images and still highlights the need to test.
This early detection is reassuring and shows the importance of vigilance, yet it shouldn’t lead to a false sense of security. Instead, it reaffirms the need for ongoing proactive security measures that combine the strengths of both human oversight and playbooks which can be deployed easily.
Numerous security teams rapidly disseminated information regarding their immediate responses and strategies to prevent similar issues in the future, illustrating the collective effort required to take swift action. The contributions, underscored by collaborative efforts, are immensely valued and show how community is essential in averting more significant incidents.
OX Security will continue to monitor this situation and provide updates as events unfold. Follow us on Linkedin and check the OX Security Blog for any developments. If you have any questions, please feel free to use the chat or email us.
Additional resources – Courtesy of Latio Tech
Here are the main links from different providers:
- Red Hat (stable, not vulnerable)
- Debian (stable, not vulnerable)
- Suse (stable, not vulnerable)
- Kali (Impacted but exploit not confirmed)
- Arch (Impacted but exploit not confirmed)
- Homebrew (Impacted but probably not exploitable)
- FreeBSD (not impacted)
- Amazon Linux (not impacted)
