Backdoor in upstream xz/liblzma leading to SSH server compromise


I liked that one - speaking as a Valgrind developer. It's almost always the same thing - blame it on a false positive. Usually it's just bugs and losers that 'know' their code is right. This time it was to hide some skulduggery.

Thankfully I don't use Linux much and still have Fedora 39 - only Rawhide and possibly 40 are affected.
 
This is beautiful.

A bold step onwards to having only government-approved operating systems allowed to access the network, for your protection.
 

nothing nefarious
Yeah, that's what it looks like on the surface. If one does not know any better, the code will be just blindly merged. And commenters are already concerned that the changes may introduce additional vulnerabilities - because the contributor is a well-known offender, for starters.

It does take being able to pay attention to details to notice stuff like that.

Man, Open Source projects are becoming almost like real jobs (complete with things like code of conduct, needing to be a skilled and trustworthy participant who can pull their own weight), only without pay.
 
All code contributed by "Jia Tan <jiat0218@gmail.com>" is suspect.

I'm pissed 'cause it hit me.

"Lasse Collin" (Larhzu https://github.com/Larhzu) was also active in the "Tucaani organization".
He tried to introduce the backdoored xz version to squashfs-tools: https://github.com/plougher/squashfs-tools/pull/276
That account was only created and active on github since November 2022, but might be worth to check his contributions too...


edit:
(corrected the year above: it's 2022, not 2023)
Larhzu also seems to be a bit fishy: https://github.com/tukaani-project/...aef377c10f71e274f63c0#commitcomment-140386085
 
It seems there is no way on github to view and check things like e.g. the signature/key fingerprint for signed commits or even just seeing the exact time including the timezone of a commit. This would make it easy to spot suspicious similarities between accounts.
Just great how crippled and annoying their UI has become...
 
Yeah, that brings up a 2016 story of a disgruntled dev who refused to rename a node.js module even in the face of a threat of a lawsuit... Just un-published that module - and broke the Internet.

or when Linus Torvalds himself got sent to counseling in 2018...

or the vicious vitriol against ZFS seen on Linux Kernel mailing list....

So yeah, there's plenty of reason for ppl to be upset - they work hard on unpaid hobbies in hopes of useful results, only to be put on blast by someone who doesn't really know what it takes to get to that point?

I believe he was taken advantage of by people who wanted to take ownership of the project:
As for this link: It looks like XZ was unmaintained and unpatched for a long time, with nobody wanting to take ownership. Yeah, it takes commitment and time, which nobody had. Everybody wanted to just submit patches, but not be stewards of the project. There's implicit expectations that project stewards either don't let it languish or find a successor who at least won't make a mess of things. I guess not everybody has the guts to frame the issue for themselves, considering that the consequences for messing up can be pretty bad. ?
 
FWIW


… some evidence that may suggest the xz maintainer is a victim, not the malicious actor. If that is the case, they're probably going to have a real bad time with how the internet's being a mob right now. Until more facts are established, please try to keep the events and person separate and focus on the former :/

(x-post of original in https://hachyderm.io/@danderson/112182299348258318 if you don't want to load twitter)
 
FreeBSD is not affected.
This was already obvious from thoroughly reading the first post about it. But then, we're not affected just because we weren't targeted. FreeBSD not being that widespread is just a soft factor making attacks less likely, but nothing that should be relied upon.

I'd still question whether the whole upstream project can be considered reliable containing lots of commits from this person (spoiler, I think no, it can't). And I'm pretty sure if FreeBSD was targeted, it's still quite likely no FreeBSD maintainer would have noticed that. The whole ecosystem can't work if you can't trust upstream projects. Opensource more or leass guarantees such things will be discovered eventually, but you'll never know how long it will take.
 
 

Attachments

  • 1711789379519.png
    1711789379519.png
    13 KB · Views: 107
FreeBSD doesn't typically take binaries from upstream, so that would have prevented the problem even if we had picked it up, as (to my understanding) it was only in the release artifacts somehow.
 
msplsh it is in the source tar all, it gets build in when the .deb is made. But it needs glibc and systemd, so we are good (for now).
 
msplsh it is in the source tar all, it gets build in when the .deb is made. But it needs glibc and systemd, so we are good (for now).
You know for sure that those backdoors in xz depend on presence of glibc and systemd? ? How?

Besides, if that were really the case, the security hole is worse than we realize, because then glibc and systemd are affected by this security bug too, by extension.

What would be the expected fallout if the backdoor is demonstrated to work without presence of glibc and systemd?
 
You know for sure that those backdoors in xz depend on presence of glibc and systemd? ? How?
The attack ultimately targets SSH, OpenSSH doesn't even depend on liblzma, but when systemd-integration is patched in, it does. As for glibc, I assume it's needed for using interception features (which work differently on different platforms).

Besides, if that were really the case, the security hole is worse than we realize, because then glibc and systemd are affected by this security bug too, by extension.
No, they're not affected, just "used".

What would be the expected fallout if the backdoor is demonstrated to work without presence of glibc and systemd?
That's impossible. Not in general of course, but impossible for this specific backdoor.
 
Back
Top