XZ Utils Backdoored?

Yep, also an alert from RedHat

And here on Ars Technica itself.

reimu240p said:

Apparently the malicious actor made commits the the linux kernel as well, scary stuff.

Click to expand...

No. That patch chain is from Lasse Collin. Jia Tan is the ne'er-do-well who backdoored xz.

TL;DR, only a real problem if you run a beta release of your Linux distro or Arch. If so, just update right away.

Some concerns over whatever else this guy did over the years, it doesn't look like his account was compromised, it looks like the real contributor is malicious. I'm sure his every commit will be checked, question is how many other bad actors are out there. Certainly not zero.

This was really sneaky. Once you see it....

I don't see the cat...

brendan_kearney said:

I don't see the cat...

Click to expand...

Yeah, I'm not much of a programmer, if someone could explain what I'm missing?

It’s the period in the line above void my_sandbox(void). It’s become a bit of a meme, since even some really skilled people who know that the period is there have trouble finding it.

My (basic, secondhand understanding) that the malicious actor inserted a conditional to check if the code compiles before enabling sandboxing. The rogue period means that this check always fails, so sandboxing never gets enabled.

What’s particularly sneaky about it is that there are less obvious ways to cause the check to fail (non-breaking space, using Cyrillic or other lookalike letters), but those would make it clear that this was intentional if and when it was discovered. A period could just be a typo.

ETA: here’s a discussion about it: https://news.ycombinator.com/item?id=39874404

There were a number of highly sophisticated elements to this attack, such that it clearly came from a nation-state level actor. Seems like they tried to make it look like China but probably actually Eastern Europe.

Anyway the guy uploaded a bunch of test files to verify compression, and they decrypted into the payload, which was cute, and disabling error checking as you noted. But the really clever bit is it checks how it's being built and omits the backdoor when compiled standalone, it's only included when compiled into a rpm or dpkg. Who's going to do that, trying to find bugs?

Moral to the story, which I assure you all the intelligence agencies are taking in hand? Debug your exploits, software quality matters, and if the public finds bugs fix them quickly.

As for avoiding recurrence, that's a much tougher problem. Many contributors want to remain effectively anonymous and use handles and single use email. You can't check every line of code. Maybe some sort of system of attribution, a web of trust sort of thing. Growing pains that I suspect will look hilariously naive looking back on this in ten years.

WoT generally doesn't scale and just changes the timescales. The Linux kernel has a rough WoT system and the entity behind the backdoor was on their way to earning that when maintainer records for xz were updated.

Considering how much OSS projects struggle to find useful contributors, a more formal WoT hindering that further will just hurt the ecosystem.

What the backdoor has demonstrated as an immediate issue is that there is a weakness in the distribution chain: there is no formal link between a tar archive used by packagers to build, and where the backdoor enabler added, and whats in version control. Mostly this is an artifact of bygone times where the VCS often didn't imclude the generated autoconf/whatever output, as that was often done as part of packaging, nor were there cryptographic hashes from the VCSs to marry to a release tag.

With practically everyone using a dVCS these days I suspect a stronger effort will be made to either verify if not directly build from a tag and matching commit id.

But the ugly truth is that this unsolvable against a determined and well resourced adversary as long as humans are involved. All that can be done is to add enough friction that critical infrastructure OSS projects are a less interesting target. And boringly it's just a repeat of what OpenSSL revealed: resource starved projects are vulnerable.

teubbist said:

With practically everyone using a dVCS these days I suspect a stronger effort will be made to either verify if not directly build from a tag and matching commit id.

Click to expand...

E.g. the Yocto Project still favors building from tarballs over clones, because they're much smaller and faster to download. It's less of an issue if you have the resources and infrastructure of RedHat or Canonical.

I saw some posts on the oss-security mailing list that some people have started auditing release tarballs and comparing them to the VCS contents. There were one or two discrepancies found so far, but fortunately they only showed that the release processes for those projects were bad.

There may be process and mechanical steps to help improve guards and protections. BUT reading that timeline by Russ Cox, Lasse Collin admits (2022-06-08) that real life events and mental health imposed on their time to dedicate to the maintainer role for XZ. We really need to support software that we rely on and attempt to give the maintainer(s) the ability to devote the time that is otherwise taken by their “day job”. So if there is a lesson here, it’s got to be that we chip in when we can and “tip your waiter”. (Yup I also just watched the John Oliver piece about food delivery apps)