Little Pig, Little Pig! Let Me Admin! (Security Thread)

[Thad]

Backdoor found in widely used Linux utility breaks encrypted SSH connections

The project is XZ Utils and the affected versions are 5.6.0 and 5.6.1. If you're using a stable release you probably aren't running either of those, but if you're using a rolling distro you might well be. (I checked the version on my Manjaro system and it was at 5.6.0; I downgraded to the previous version, 5.4.6.) Looks like it made it into Debian Testing too. I'm seeing reports that 5.6.x is also in Mac package managers like Homebrew and MacPorts. I'd expect that means there are affected repos for other BSDs too, though I'm not sure if any of them are actually affected by the vulnerability since it appears to target SSH builds that are linked against systemd, but probably best to downgrade anyway; better safe than sorry.

If you don't know what any of that shit means then the vulnerability almost certainly doesn't affect you.

[Thad]

Adding: I've been following the comments on the article and there are a couple of good links in there. Andres Freund says it only affects x86-64 architecture, packages built with gcc and the GNU linker, and running on Debian or an RPM-based distro, and suggests that these constraints are probably there to make the issue harder to reproduce.

Still, downgrade anyway, just in case. (I did, even though Manjaro and other Arch-based distributions should be unaffected.)

[JD]

Ubuntu 24.04 LTS comes out in a month. If this hadn't been spotted, it may well have made it into a major version used by a lot of servers and desktop users.

[Thad]

Yeah, per this bug report it looks like they were planning to ship 24.04 with xz-utils 5.6.0, and the maintainer (or someone pretending to be them) was asking them to bump it to 5.6.1.

A quick glance at Ubuntu's version of xz shows that it links against lzma, so it could be vulnerable to the backdoor based on that. But I'm not sure about this bit from Freund's e-mail:

Code: Select all

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

So that means it'll run on anything that either uses RPM on x86/64 architecture, or has a debian/rules directory under source. But I'm not sure whether debian/rules is something you see in downstream distros or just Debian itself; I don't know if Ubuntu would be affected or not off the top of my head.

Regardless, yeah, they rolled back, of course.

[Thad]

Jonathan Corbet:

Random, unordered, probably useless thoughts on today's apocalypxze...

Part of the success in getting this into Debian may be the result of there being no xz maintainer there. It is "maintained" by people whose attention is normally elsewhere doing occasional non-maintainer updates.

This code will have been running on the machines of a lot of distribution maintainers. If it has already been exploited, it could be that its real purpose has already been achieved and the real problem is now elsewhere. I sure hope somebody can figure out a way to determine if this backdoor has been used.

The multi-front nature of the attack, including multiple efforts to get the malicious code installed more widely more quickly, suggests we're not just dealing with a lone sociopath. I fear we'll never know who was really behind this, but I would sure like to.

There is surely more where this cam from.

An interesting thought. Maybe the point was never to get into wide release but to compromise package maintainers with the two biggest upstream distros.

[Mazian]

Code: Select all

if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then

So that means it'll run on anything that either uses RPM on x86/64 architecture, or has a debian/rules directory under source. But I'm not sure whether debian/rules is something you see in downstream distros or just Debian itself; I don't know if Ubuntu would be affected or not off the top of my head.

Yes, that directory layout would be common to all derivative distros.

More information on reverse-engineering it should be forthcoming.

[Thad]

The best rundown I've seen of the sequence of events is from Evan Boehs, and...it's really fucking fascinating. I recommend everybody give it a read, even nontechnical people; even if you don't know the jargon you can still appreciate just how elaborate a scheme this was. It took place over a period of almost two years, with the attacker gaining trust on a key project (including the use of a likely sockpuppet to advocate that they take over the project), convincing Google to disable a particular feature in a security analysis tool that would have caught the exploit (the rationale for disabling it was a performance bug that was introduced by an account that was likely another sockpuppet), and then advocating for the version with the exploit code to be included in debian-testing and then get added to Ubuntu right before the beta freeze for the next major release.

It's fucking wild.

And they almost got away with it, except a Microsoft dev started wondering why SSH was using so much CPU even when connections failed, and happened to remember a seemingly unrelated bug report he'd seen earlier.

Although, on the other hand, it also came very close to shipping with an updated systemd that would have cut off the attack vector.

[nosimpleway]

wait it's called liblzma

I assume everyone's already done the requisite joke already

[Upthorn]

libelzma balls?

[Friday]

if it is not posted in one thread, it will be posted in another thread

[Thad]

XZ Backdoor: Times, damned times, and scams

Based on timestamps from his commits, they believe "Jia Tan" is probably in eastern Europe (or possibly Israel) but wants people to think he's in China.

He also once committed under the name "Jia Cheong Tan" which, AIUI, is another clue that he's not Chinese as it mixes two different dialects. (I've never studied Chinese and can't vouch for that, but I've seen some discussion to that effect.)