Backdoor in upstream xz/liblzma leading to SSH server compromise

github.com

liblzma: Fix false Valgrind error report with GCC. · tukaani-project/xz@82ecc53

With GCC and a certain combination of flags, Valgrind will falsely trigger an invalid write. This appears to be due to the omission of instructions to properly save, set up, and restore the frame p...
github.com github.com

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.
 
suntzu00 said:
github.com

Merge pull request #1609 from JiaT75/added_error_message_to_warning_b… · libarchive/libarchive@e37efc1

…sdtar_1561 Added error text to warning when untaring with bsdtar
github.com github.com

nothing nefarious
Click to expand...
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.
 
rbranco said:
All code contributed by "Jia Tan <jiat0218@gmail.com>" is suspect.

I'm pissed 'cause it hit me.
Click to expand...

"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?

rbranco said:
I believe he was taken advantage of by people who wanted to take ownership of the project:

Re: [xz-devel] XZ for Java

www.mail-archive.com www.mail-archive.com
Click to expand...
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

Dave Anderson (@danderson@hachyderm.io)

I guess without the CW just to be a bit louder: https://twitter.com/birchb0y/status/1773871381890924872 found 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...
hachyderm.io hachyderm.io

… 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)
Click to expand...
 
T-Aoki said:
FreeBSD is not affected.
Click to expand...
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.
 
xz-utils backdoor situation ◀ Everything I know about the XZ backdoor ◀ <https://news.ycombinator.com/item?id=39868673>

CVE-2024-3094 | Tenable®

Urgent security alert for Fedora 41 and Fedora Rawhide users ◀ Malicious backdoor spotted in Linux compression library xz • The Register

CVE-2024-3094- Red Hat Customer Portal – critical, 10.0 (pictured) … I don't often see that (understatement)

All about the xz-utils backdoor | Kali Linux Blog ◀ <https://infosec.exchange/@kalilinux/112181399271675981>

Filippo Valsorda: "I'm watching some folks reverse engineer the xz backdoor, sharing some *preliminary* analysis with permission. The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system(). It's RCE, not auth bypass, and gated/unreplayable." — Bluesky ◀ <https://abyssdomain.expert/@filippo/112185827553387306>

<https://fosstodon.org/@kernellogger/112185083481646580> ▶ XZ Utils backdoor (Lasse Collin) ◀ <https://old.reddit.com/r/linux/duplicates/1brhlur/xz_utils_backdoor/>


The Internet will be awash with information. I might add to, or reorder, the shortlist above, but it's not occupying my Easter weekend :)
 

Attachments

  • 1711789379519.png
    1711789379519.png
    13 KB · Views: 57
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).
 
Crivens said:
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).
Click to expand...
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?
 
astyle said:
You know for sure that those backdoors in xz depend on presence of glibc and systemd? 😲 How?
Click to expand...
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).

astyle said:
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.
Click to expand...
No, they're not affected, just "used".

astyle said:
What would be the expected fallout if the backdoor is demonstrated to work without presence of glibc and systemd?
Click to expand...
That's impossible. Not in general of course, but impossible for this specific backdoor.
 
You must log in or register to reply here.
Back
Top