The vulnerability was added with surgical precision: They added a test for a "corrupted" compression file to justify adding a binary blob to the repo, and the binary blob injected the payload into the source code. Furthermore, over a year earlier, the attacker disabled the specific type of fuzzing that would have caught this vulnerability from Google's security scanner
Here's where the rabbit hole begins. I recommend reading the comments of this Hacker News post as well, since most of this post is taken from there: https://news.ycombinator.com/item?id=39865810
Insight from someone who worked with the attacker:
rwmj wrote: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.
Hilarious joke referencing the time the US intelligence community planted malware on another country's nuclear powerplant:
wyldfire wrote: No. But if you have any centrifuges they will probably exhibit inconsistent behavior.
Theorycrafting on how the person got permissions to push directly to xz:
mrb wrote:I would presume it's a state actor. Generally in the blackhat world, attackers have very precise targets. They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency who is interested in surveilling, well, everything.
Or it could in theory be malware authors (ransomware, etc). However these guys tend to aim at the low hanging fruits. They want to make a buck quickly. I don't think they have the patience and persistence to infiltrate an open source project for 2 long years to finally gain enough trust and access to backdoor it. On the other hand, a state actor is in for the long term, so they would spend that much time (and more) to accomplish that.
So that's my guess: Jia Tan is an employee of some intelligence agency. He chose to present an asian persona, but that's not necessarily who he truly represents. Could be anyone, really: Russia, China, Israel, or even the US, etc.
Edit: given that Lasse Collin was the only maintainer of xz utils in 2022 before Jia Tan, I wouldn't be surprised if the state actor interfered with Lasse somehow. They could have done anything to distract him from the project: introduce a mistress in his life, give him a high-paying job, make his spouse sick so he has to care for her, etc. With Lasse not having as many hours to spend on the project, he would have been more likely to give access to a developer who shows up around the same time and who is highly motivated to contribute code. I would be interested to talk to Lasse to understand his circumstances around 2022.
hk__2 wrote:> I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.
https://www.mail-archive.com/xz-devel@t ... msg00567.h...
mrb wrote:Dated June 2022. Good find!
Someone from 1Password also immediately tried to update xz on a dormant Go wrapper in this Github repo, although it seems to be an innocent mistake: https://github.com/jamespfennell/xz/pull/2 (take that as you will given the sophistication of this attack)
The Debian maintainers seemed against updating xz to 5.6.x without a good reason, but got pressured by a bunch of accounts: https://bugs.debian.org/cgi-bin/bugrepo ... ug=1067708
The author of the vulnerability also has some Linux kernel patches.. Notably this one which introduces a potential RCE by piping output (aka very bad, possibly worst type of vulnerability): https://git.kernel.org/pub/scm/linux/ke ... b78e3#n528