XZ Utils CVE-2024-3094: A Tale of Broken Trust, Curious Persistence, and a Call to Action

What Is XZ Utils and What Happened?

XZ Utils is an open source software commonly found in most Linux distros, although CVE-2024-3094 is only present in XZ Utils versions 5.6.0 and 5.6.1, meaning only the Linux distros using these newer versions are vulnerable. The vulnerability was discovered and reported by open source developer, Andres Freund, who found the vulnerability while investigating an anomaly in the behavior of the sshd process (a protocol used for secure remote login and file transfer). He observed that sshd was utilizing an unusually high amount of CPU resources and exhibiting a significant slowdown during the login process. 

What he discovered was a backdoor. Initial investigations have indicated that the backdoor was not directly introduced into the liblzma library. Instead, it was covertly embedded within binary test files in the XZ compressed format to appear innocuous. This was a later step in an intentional long-game effort by a persistent threat with the intent of gaining trust in the community in order to more covertly drop this trojan horse into the code base undetected. Insider threat and social engineering are not simple categories of attacks to combat and their likelihood and risk should be taken into account at every layer of a robust defense-in-depth strategy. 

What’s the Impact?

The backdoor, found in the liblzma library component of XZ Utils and stored inside the standard XZ tarballs within the code repository, could have enabled threat actors to bypass SSH authentication and gain unauthorized remote access to internet-connected machines running on certain Linux distributions. While the initial investigations suggest the potential for SSH authentication bypass, researchers believe that the backdoor might have been designed to facilitate more sophisticated attacks or exploit additional undiscovered conditions, which is still being investigated as of this writing. Some analysis also seems to confirm that the backdoor enables remote code execution on targeted systems, granting the threat actors complete control over compromised machines.

The other recognized negative impact of this vulnerability is the explicit abuse of trust. Trust is the foundation of open source, and really the foundation of most technology. This breach of trust was deliberate and calibrated, with the author of the backdoor working to become a maintainer and contributing to the project for two years before introducing this vulnerability. There’s no simple solution for open source maintainers to see through the calculated social engineering tactics of a persistent attacker. Open source is always looking for another good contributor to help out. So, when nefarious intent is embedded into the purpose of the trust exercise, it can make it hard to trust again. This is a people problem with a ripple effect far beyond the technical impact of the vulnerability itself.

Taking Action to Secure Open Source

As enterprises and organizations that build, maintain, and utilize software, whether we acknowledge it or not, we are all dependent on open source software. It’s a shared value and a shared risk. Additionally, security for open source is just as complex as security for a commercial enterprise. The same needs for defense-in-depth and for more resources and security talent plague us all. This is a tragedy of the commons. We use this technology for improvements and critical dependencies throughout the environment. But, on the whole, we don’t feel like we own it, therefore we don’t act upon the admission that we must also contribute back to the defense strategy. 

There are ways to help and turn words into action: 

• Look into participation in the foundations that support the open source you depend on (e.g., OpenJS Foundation, Linux Foundation, Ruby Central, Apache Software Foundation). 
• Look into OpenSSF, a Linux Foundation project working to secure critical open source. Through OpenSSF you can contribute financially as a sponsor or through direct resources allocation in Working Groups. 
• For more direct control and engagement, create a sponsored program internally where your engineering resources get a percentage of their time to put hands on keyboard to help maintain the open source projects your organization depends on. 

At HackerOne, we host the Internet Bug Bounty program. Many years back the question was asked, how can hackers help secure open source software? We know that bug bounty programs are effective continuous testing solutions, and we wanted to facilitate a program that would fit the unique needs of the open source community. This pooled defense bug bounty program was built specifically to incentivize security research into shared open source software and importantly, to support the critical remediate efforts taken on by maintainers to secure the code. If you’re a HackerOne customer, you can join at any time through your program on the platform. If you’re a maintainer of a widely adopted open source project and are looking for additional resources to support the discovery and remediation of vulnerabilities in your project, reach out to us: ibb@hackerone.com. 

This is the time for enterprises and organizations to take action on our words. We acknowledge that open source is critical to our success and verbally support the importance, yet we still fail to take appropriate actions to secure it. We’ve laid out some possible actions that can be taken to help secure open source, and we can do better.