NIGHTMARE SUPPLY CHAIN ATTACK SCENARIO — What we know about the xz Utils backdoor that almost infected the world Malicious updates made to a ubiquitous tool were a few weeks away from going mainstream.
Dan Goodin – Apr 1, 2024 6:55 am UTC EnlargeGetty Images reader comments 70
On Friday, a lone Microsoft developer rocked the world when he revealed a backdoor had been intentionally planted in xz Utils, an open source data compression utility available on almost all installations of Linux and other Unix-like operating systems. The person or people behind this project likely spent years on it. They were likely very close to seeing the backdoor update merged into Debian and Red Hat, the two biggest distributions of Linux, when an eagle-eyed software developer spotted something fishy.
Further ReadingBackdoor found in widely used Linux utility targets encrypted SSH connections”This might be the best executed supply chain attack we’ve seen described in the open, and it’s a nightmare scenario: malicious, competent, authorized upstream in a widely used library,” software and cryptography engineer Filippo Valsorda said of the effort, which came frightfully close to succeeding.
Researchers have spent the weekend gathering clues. Here’s what we know so far.
What is xz Utils?
xz Utils is nearly ubiquitous in Linux. It provides lossless data compression on virtually all Unix-like operating systems, including Linux. xz Utils provides critical functions for compressing and decompressing data during all kinds of operations. xz Utils also supports the legacy .lzma format, making this component even more crucial.
What happened?
Andres Freund, a developer and engineer working on Microsofts PostgreSQL offerings, was recently troubleshooting performance problems a Debian system was experiencing with SSH, the most widely used protocol for remotely logging in to devices over the Internet. Specifically, SSH logins were consuming too many CPU cycles and were generating errors with valgrind, a utility for monitoring computer memory.
Through a combination of sheer luck and Freunds careful eye, he eventually discovered the problems were the result of updates that had been made to xz Utils. On Friday, Freund took to the Open Source Security List to disclose the updates were the result of someone intentionally planting a backdoor in the compression software. Advertisement
What does the backdoor do?
Malicious code added to xz Utils versions 5.6.0 and 5.6.1 modified the way the software functions when performing operations related to lzma compression or decompression. When these functions involved SSH, they allowed for malicious code to be executed with root privileges. This code allowed someone in possession of a predetermined encryption key to log in to the backdoored system over SSH. From then on, that person would have the same level of control as any authorized administrator.
How did this backdoor come to be?
It would appear that this backdoor was years in the making. In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint funcion with a variant that has long been recognized as less secure. No one noticed at the time.
The following year, JiaT75 submitted a patch over the xz Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of xz Utils, hadnt been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.
In January 2023, JiaT75 made their first commit to xz Utils. In the months following, JiaT75, who used the name Jia Tan, became increasingly involved in xz Utils affairs. For instance, Tan replaced Collins’ contact information with their own on oss-fuzz, a project that scans open source software for vulnerabilities that can be exploited. Tan also requested that oss-fuzz disable the ifunc function during testing, a change that prevented it from detecting the malicious changes Tan would soon make to xz Utils.
In February of this year, Tan issued commits for versions 5.6.0 and 5.6.1 of xz Utils. The updates implemented the backdoor. In the following weeks, Tan or others appealed to developers of Ubuntu, Red Hat, and Debian to merge the updates into their OSes. Eventually, one of the two updates made its way into the following releases, according to security firm Tenable: Distribution Advisory Notes Fedora Rawhide https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users Fedora Rawhide is the development distribution of Fedora Linux Fedora 41 https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1. https://lists.debian.org/debian-security-announce/2024/msg00057.html openSUSE Tumbleweed and openSUSE MicroOS https://news.opensuse.org/2024/03/29/xz-backdoor/ Backdoored version of xz was included in Tumbelweed and MicroOS between March 7 and March 28 Kali Linux https://www.kali.org/blog/about-the-xz-backdoor/ Backdoored version of xz was included in Kali Linux (xz-utils 5.6.0-0.2) between March 26 and March 28
Theres more about Tan and the timeline here. Page: 1 2 Next → reader comments 70 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Advertisement Promoted Comments Christarp The whole world got lucky that one developer was determined enough to discover the cause of a minor performance regression. Just makes you wonder what else hasn’t yet been discovered in our open source tooling out there.
Really eye opening, thank you Andres!
Edit: And of course, Dan for the wonderful article. April 1, 2024 at 7:16 am BarnSoftEng It should be noted that the attack only works because Debian and Redhat added functionality to sshd that is not present in it as distributed by its developers. The extra functionality adds systemd interaction, which requires libsystemd which requires liblzma, a component of the (compromised) xz package.
One should be wary of distributions adding functionality. Often it increases the attack surface, not only because of the modifications/additions themselves, but also by adding dependencies.This conclusion ignores the huge value that the patches that all OS apply to packages provides. Without patches much upstream software will not build, will not run correctly. April 1, 2024 at 7:49 am pseudonomous It should be noted that the attack only works because Debian and Redhat added functionality to sshd that is not present in it as distributed by its developers. The extra functionality adds systemd interaction, which requires libsystemd which requires liblzma, a component of the (compromised) xz package.
One should be wary of distributions adding functionality. Often it increases the attack surface, not only because of the modifications/additions themselves, but also by adding dependencies.
While this is true, to a degree, it’s also quite possible that if there were a lot of interesting targets out there that didn’t patch sshd to use systemd and libxz, that given the level of access they had, the actor here could almost certainly found some other way to put an obfuscated backdoor into the code.
I mean, certainly the OpenSSH project is obviously in the clear, but having gained commit access to a critical library, I don’t think we could feel safe that "Jia Tan" couldn’t have constructed a different backdoor even if they couldn’t use the particular behavior Debian and Ubuntu added to their version of SSH.
And I’m not sure anybody feels totally safe until somebody audits the code to make sure there’s nothing else lurking in here that might be dangerous. April 1, 2024 at 7:50 am BarnSoftEng So a prime reason this became potentially exploitable is libsystemd in OpenSSH. Need I say more.The prime reason is a very well funded and capable attacker looked for a way in.
if not xz or systemd then they would have attacked via the next candidate weak point. April 1, 2024 at 7:51 am om1 The prime reason is a very well funded and capable attacker looked for a way in.
if not xz or systemd then they would have attacked via the next candidate weak point.I do know that the OpenSSH devs are very strict on not increasing attack surface. The main reason why they did not want to link to systemd in the distributed version. You can be sure that OpenSSH as distributed contains less opportunity for attackers than the modified versions. That’s my main point: modifications by distributions are not always improvements. April 1, 2024 at 8:20 am MikeGale We are lucky that this was detected and that some competent people have moved in to analyse. I presume more analysis is still being done. (Thanks to them.)
What we don’t know is how many other similar attacks have been deployed, and how many are in preparation.
What can decent people do to reduce our risks?
Thoughts that come to mind:
1. Some of those who do this, often thankless, maintenance work might like more support. This might be financial contributions, or people (who know what they’re doing) reviewing code submissions. Those who incorporate these libraries into their own programs (and all users) should maybe think about this. If there were a "donate to the maintainers" button on a story like this, that would convert the immediate story into something of greater value, if the maintainer would like that.
2. Some of the maintainers might appreciate recognition. Some won’t, but worth considering.
3. Some who use the libraries can improve the checking they do.
4. Unpleasant people who harass maintainers should be detected and treated appropriately. April 1, 2024 at 9:17 am TheMongoose "This developer persona has touched dozens of other pieces of open-source software in the past few years.". Well, I guess the Opensource community have some codes to review. Maybe the xz incident is only the tips of the iceberg.Right? I didnt realise until I read this article just how far back this started. Now youve got to wonder: if this was a group, how many other so-far benign identities they have, contributing good code and building up reputations. And how easy it would be for them to slip a little something into another fundamental tool. April 1, 2024 at 9:18 am Channel Ars Technica ← Previous story Next story → Related Stories Today on Ars
