Deep Dive on the XZ Backdoor: CVE 2024-3094 Enables Remote Code Execution in XZ (5.6.0-5.6.1)
May 1, 2024
On March 29, a perceptive developer realized a backdoor had been maliciously inserted by a project maintainer into xz/liblzma, an open-source compression library used by many Linux distributions.
The backdoor, now given the identifier CVE-2024-3094 (and previously covered in our blog) enables SSH authentication bypass. If a machine listens on port 22, the backdoor enables an attacker to execute arbitrary privileged code on the machine, without any authentication.
5.6.0 and 5.6.1 are the only versions impacted by CVE-2024-3094.
Both versions are new and were not yet integrated into mainstream projects, which lowers the amount of vulnerable machines overall. A new version, 5.6.1-2, has been released without the backdoor code.
However, maintainers of projects that use this dependency are divided in their approach to this CVE because of the malicious nature of the code inserted—and the fact that the contributed code was from a maintainer who had been making contributions since 2021 (and had direct push access since January 2023).
While at least some of the user’s contributions appear benign, security-conscious users are wary of any code inserted after he gained access. This is especially true since direct push access would have allowed the attacker to forge contributor names for other commits, so there is no true way to tell which commits since January 2023 came from him.
The attack shows a high level of planning and commitment that is unusual in these settings, suggesting the possibility of a nation-state actor engaging in a “long con.” “Jia Tan” appears to have befriended the original maintainer of XZ over a period of months or years in order to take over and obtain direct push access.
For maintainers of Linux distros, the question is now: update or roll back?
While version 5.6.1-2 has removed the code that created the backdoor, “Jia Tan” had over 750 commits dating back years. Reverting to a version before any of Jia Tan’s contributions would mean going back to version 5.3.2alpha, while reverting to a version before he had direct push access would mean reverting to 5.4.1.
However, reverting to either of these versions is complicated and would introduce breaking changes. Anyone reverting in this way would also have to apply security fixes to those earlier versions to ensure that they did not introduce other vulnerabilities.
At this time, there is no direct evidence that other versions have been impacted, or that other malicious code was inserted in previous versions. Because of this, updating to 5.6.1-2 is the simplest solution at this time.
Of course, Oligo will keep you up to date about any new information or vulnerabilities discovered in the wake of these findings—watch this space for more!
Many CVE management solutions depend on NVD , which has not analyzed the vulnerability yet, making it invisible in many security solutions.
Oligo’s Application Security Posture dashboard enables you to find if your organization was impacted by CVE-2024-3094, even though the CVE is missing in many databases and SCA/SAST tools.
xz” and see if it was executed anywhere inside your environment.If xz was executed, and the version is 5.6.0 or 5.6.1, you are vulnerable and might have been compromised. At this time, our Oligo ADR product has not observed any incidents with the XZ backdoor being exploited at any time, for any of our customers (and our testing indicates that the product would identify these intrusions instantly).
If xz is only Loaded to memory or Never Executed, you have not been impacted.
Every time a new critical vulnerability is identified in a commonly used dependency, security and engineering teams have to check to see if they’re impacted. Typically, they use static scanning tools like SCA to make this determination.
But in an SCA tool, if the vulnerable dependency appears anywhere (whether or not it is actually loaded and whether or not the vulnerable function is executed), the scan generates an alert.
Most of these alerts aren’t useful—instead, they’re false positives that could never actually impact the software in runtime. Eventually, developers treat them accordingly. If the fire alarm goes off all the time when there’s no fire (or planned drill) going on, people start to ignore it.
Oligo works differently. Instead of using “reachability” analysis to make educated guesses about what functions may be called at runtime, the Oligo sensor uses patented eBPF technology to actually observe application behavior in realtime. Oligo Focus can determine exactly which libraries and functions are executed, with proof your teams can see.
And the other half of the Oligo platform, Oligo ADR, can automatically detect when applications behave improperly—so even if another part of this library’s code was compromised, any actual exploitation could be identified by Oligo even before those vulnerabilities are identified or assigned a CVE.
Whether you’re interested in how to approach the XZ backdoor or want to see how Oligo can cut customers’ vulnerability backlogs by 99% in a single day, we’d love to hear from you—so get in touch!
Oligo helps organizations focus on true exploitability, streamlining security processes without hindering developer productivity.
