Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

771–780 of 1001 posts

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#771

Something about this I found surprising is that Linux distros are pulling and packaging pre-built binaries from upstream projects. I'd have expected them to build from source.

They were pulling a tarball from upstream and building it - the tarball was compromised.

The answer is not complete. There were 2 ways to pull sources:

bad - https://github.com/tukaani-project/xz/releases/download/...

or:

good - https://github.com/tukaani-project/xz/archive/refs/tags/...

Specifically in Gentoo, there is a note in https://github.com/gentoo/gentoo/blob/master/app-arch/xz-uti...

  # Remember: we cannot leverage autotools in this ebuild in order
  #           to avoid circular deps with autotools
Namely, to unpack autoconf-2.72e.tar.xz from gnu.org you need xz-tools. And this is just the shortest circle. It is not very common, but xz-utils was one of few rare cases where regeneration of autohell files was considered as unnecessary complication (it backfired).

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#772
post #640

This is why the less the better... even if it means less comfortable... to a certain point obviously. And that includes SDKs...

I don't understand why you were downvoted. Having fewer moving parts does make it easier to catch issues.

Everything which is not engaging in licking Big Tech balls (open source or not) on HN is served with severe downvoting, that most of the time (probably real trash human beings or AI trolls with headless blink/geeko|webkit).

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#773
post #755

I guess that rewriting liblzma in Rust would not have prevented this backdoor. But would have likely increased the confidence in its safety. Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.

This hack exploited a fairly unique quirk in the linux C ecosystem / culture. That packages are built from "tarballs" that are not exact copies of the git HEAD as they also contain generated scripts with arbitrary code. It would not have happened in any modern language. It probably wouldn't have even happened in a Vistual Studio C-project for windows either.

Funny you should say that, given they definitely have exploit code in `vcpkg`

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#775
post #514
post #42

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 proj…

GitHub has suspended @JiaT75's account. EDIT: Lasse Collin's account @Larhzu has also been suspended. EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page. -- EDIT: Just did a bit of poking. xz-embedded was touched by Jia as well and it appears to be used in the linux kernel. I did quick look and it doesn't appear Jia touched anything of interest in there. I also checked the…

> EDIT: Github has disabled all Tukaani repositories, including downloads from the releases page.

Why? Isn't it better to freeze them and let as many people as possible analyze the code?

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#776

Github making suspect repository private and hiding recent account activity is wrong move and is interfering with citizens investigation efforts.

It's a crime scene. It effectively has the "police" yellow tape around it.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#777
Please note: the changes have been made after GitHub has enforced 2FA (certainly not for "better security", but for promotion of FIDO2 and Windows Hello biometric impl of FIDO2, see https://codeberg.org/KOLANICH/Fuck-GuanTEEnomo for more info. Until recent times (for now access via git protocol is blocked for my acc, I guess based on lack of 2FA set up) it was even possible to push into all repos one has access by just using single-factor SSH key even without enabling 2FA in the account). As I have warned, nothing will protect when a backdoor is introduced by a malicious maintainer, or a "smart entrepreneur" who sold his project to a ad-company, or a loyal "patriot" living and earning money within reach of some state, or just a powerless man who got an offer he can't refuse. In general supply chain attacks by "legitimate" maintainers cannot be prevented. "Jia Tan" is just a sockpuppet to mitigate consequences to maintainers to make it look like they are not involved into it. They surely are. At least according to the current info it were they who have given the malicious account the permission to publish releases on behalf of the project and access to the repo.

IMHO all maintainers of the backdooored projects anyhow related to accepting the malicious changes should be considered as accomplices and boycotted. We don't need evidence of their liability, it is they who need to maintain their reputation. We are just free to take our decisions based on their reputation. Even if they were hacked themselves, it is not our problem, it is their problem. Our problem is to keep ourselves safe. It may feel "unjust" to ruin reputation of a person based on the fact he may be cheated or hacked… But if a person can be cheated or hacked, why should he/she have such a good reputation as everyone else?! So, it makes a lot of sense to just exclude and replace everyone, for whome there exists evidence of comprometation, no matter due to unconcern or malice. But FOSS is a doocracy serving products at dumpling prices ($0, free of charge), and for majority backdoored software is completely acceptable given that they get them free of charge. And powerful actors who can afford to pay for software will just hire devs to develop their private versions, while allowing the public to pay $0 for their free versions and use the backdoors placed into them themselves. In other words a complete market failure.

I think that 1. xz project must be shut down completely. I mean projects should stop using it as a dependency, exclude from distros, boycott it. LZMA algo was developed by Igor Pavlov in 7z project, but somehow it has happenned that liblzma was developed and maintained by unrelated folks. liblzma should be developed as a part of 7z project taking no code other than the trivial one for API compatibility adapter from xz. 2. Projects created by compromised authkrs should be boycotted. 3. Other projects touched by the compromised devs/maintainers should be audited. 4. All the projects using autotools should be audited and must replace autotools with cmake/meson. Autotools is a piece of shit, completely uncomprehensible. There is no surprise it was used to hude a backdoor - according to my experience in FOSS noone likes to touch its scripts anyhow. 5. No project should be built from releases. Project should be built from git directly. Implementing full support of SHA256 in git and git forges (GitHub, GitLab, Codeberg, sr.ht) should be accelerated to mitigate attacks using collisions to replace approved commits (I guess the randomness can be concealed from reviewer's eye in binary resource files, like pictures).

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#778

chmod u+x running detect_sh script just runs with no output on my arch linux box? https://www.openwall.com/lists/oss-security/2024/03/29/4

Yes, Arch Linux’s OpenSSH binary doesn’t even link to liblzma, which means your installation is not affected by this particular backdoor. The authors of the `detect_sh` script didn’t have that scenario in mind, so the `ldd` invocation never finds a link and the script bails early without a message.

Thanks!

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#779

Well isn't this an interesting commit. He finished his inject macro to compose the payload at build, so now he can start clearing up the repo so none of that shit gets seen when cruising through it. https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4323bc3e0c1...

That's not what gitignore does. I can't think of a way it would let you hide this exploit.

Accidentally committing it.

Re: Backdoor in upstream xz/liblzma leading to SSH server compromise

#780
post #537
post #42

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 proj…

After reading the original post by Andres Freund, https://www.openwall.com/lists/oss-security/2024/03/29/4 , his analysis indicates that the RSA_public_decrypt function is being redirected to the malware code. Since RSA_public_decrypt is only used in the context of RSA public key - private key authentication, can we reasonably conclude that the backdoor does not affect username-password authentication?

Isn't it rather that the attacker can log in to the compromised server by exploiting the RSA code path?
Post reply on HN