There’s a lot of media articles out there covering CVE-2024-3094 and, as usual, a lot of them are hyped up and covered in annoying adverts. So, I wanted to put together a “short story” version of the situation.
The very short story is that a threat actor managed to add malicious code into XZ Utils versions 5.6.0 and 5.6.1. This malicious code could then impact the security of software linked against this library – one critical target of this was OpenSSH. The backdoor could make OpenSSH vulnerable to remote command execution via SSH authentication bypass. Red Hat, Inc gave this issue a CVSS 3.1 score of 10.0 – Critical.
The story starts in an interesting place, with an email to the OSS Security mailing list stating:
“The upstream xz repository and the xz tarballs have been backdoored.”
You might not be aware of XZ or liblzma (part of the xz package), but it’s a library used by a wide range of software for compression and decompression of data. A threat actor managed to add malicious code to the xz tarballs which was heavily obfuscated. The malicious code was contained in a “disguised test file” and was found to interfere with OpenSSH. Although OpenSSH is not directly linked to liblzma, the malicious code was able to interfere with it as it communicated with systemd, which does link to the library.
Thanks to an early discovery, the malicious package didn’t spread as far as it could have, but it did reach some systems – for example, Fedora 41 (and Rawhide), Debian testing and Kali Linux.
The malicious code was discovered, according to the post to the OSS Security mailing list, after a software developer (Andres Freund, a Postgres developer at Microsoft) noticed some strange observations. Several mainstream media posts put this down to him noticing a 500ms delay in bot logins against SSH – however Andres himself put it down to noticing failing ssh logins with incorrect usernames using a substantial amount of CPU, which in turn led to noticing the slower logins.
These observations led to finding malicious code within the XZ Utils package, and security researchers looked for the source of this code. This appeared to be a long term contributor to the library. The contributor established themselves over multiple years before adding the malicious code. This was attributed to the (now suspended) GitHub account @JiaT75 (Jia Tan), which was a contributor to other repos, which led to a comment I found funny on the oss-fuzz repo:
“Given that the recent backdoor of xz/libzma is being attributed to the GitHub account @JiaT75, their contact info should probably be removed from google/oss-fuzz and the correct contacts should be determined.”
The hedged language of “should probably be” just seemed a funny choice to me, given the circumstances.
A lot of people are pointing to this backdoor as a prime example of a “Supply Chain Attack”, given the impact it could have had on OpenSSH. Others are pointing to it as an example of a highly sophisticated attack typical of nation-state sanctioned threat actors, given the length of time between first contribution and the placing of the backdoor. Others pointed to the lack of information about the contributor outside of the code commits (meaning there appears to be little information available about who, or where, they are) saying it shows specific intention here, distinguishing this from a benevolent developer gone rogue.
Several people blamed the fact that XZ Utils is a relatively small project, with a no doubt somewhat overwhelmed maintainer at the helm, for the fact that a new contributor could come along and offer to help and build up trust over time to allow for this kind of backdoor to be placed. However, Andres Freund added his view that there are likely a few large and crucial projects out there where something small could be hidden in a larger change, even without a lot of prior contributions to the project.
The specifics of Jia Tan getting maintainer access are interesting though, for example Jia Tan posted several patches to the project prior to getting this access which were effectively upvoted by other people alongside complaints of the slowness of project progress. With one adding:
“Is there any progress on this? Jia I see you have recent commits. Why can’t you commit this yourself?”
However, the person posting this appears to have come out of nowhere in June 2022 and then disappeared again. It’s not beyond the realms of possibility that these “boosting” accounts putting pressure on the person running XZ were simply sock puppet accounts by Jia Tan to get maintainer access.
Many people appear to be attributing this to some Nation-State threat group, throwing around the usual suspects such as China, Russia, and North Korea. With others pointing out that it’s unlikely to have been a Chinese threat actor as they appeared to work through notable Chinese holidays – and in turn added countries like Iran and Israel to the list.
Given the sophistication of the obfuscations of the backdoor, the patience to wait so long before planting it, and the anonymity of the author – it certainly could have been nation-state threat group with long-term goals in mind. However, never underestimate the dedicated, solo, threat actor who simply has time on their hands (and possibly multiple sock puppet accounts).
The only thing that is certain is that we have constructed a society intrinsically dependent on open-source software, that is often built and maintained by overworked volunteers and supply chain attacks like this, are an ongoing concern.
Systems can be checked to see if they are impacted by reviewing which version of XZ Utils is installed, for example on Debian and Kali this could be done with the following command:
apt-cache policy liblzma5
This will show which version of liblzma5 is installed, and version 5.6.0 and 5.6.1 are affected. However, Kali have released a version called “5.6.1+really5.4.5-1” which, as the name suggests, is really a downgrade to avoid the backdoored versions.
Read More
What do you mean by Threat Actor?
Habitually in our articles we use the term “Threat Actors” where you might expect us to use a term like “attacker” or “cybercriminal”. So why do we do that? In short, we find that threat actor is a more accurate term where something like “cybercriminal” may, in some cases, be [...]| Play | Cover | Release Label |
Track Title Track Authors |
|---|