Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

641–650 of 1001 posts

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

#641
post #581

Earlier quoted context omitted.

I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.

As I said recently in a talk I gave, 2FA as implemented by pypy or github is meaningless, when in fact all actions are performed via tokens that never expire, that are saved inside a .txt file on the disk.

Passwords have full scope of permission while session tokens can be limited.

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

#642
post #18

That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.

Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.

Autoconf is m4 macros and Bourne shell. Most mainstream programming languages have a packaging system that lets you invoke a shell script. This attack is a reminder to keep your shell scripts clean. Don't treat them as an afterthought.

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

#643
post #639
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…

Do you know if it was actually the commit author, of if their commit access was compromised?

If it was a compromise it also included the signing keys as the release tarball was modified vs the source available on GitHub.

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

#645

A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.

Internet detectives at work in this thread!

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

#646

A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.

Suddenly anything like that becomes super suspicious.

I wonder how this will affect the OS community in general.

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

#647
post #574

For bad-3-corrupt_lzma2.xz, the claim was that "the original files were generated with random local to my machine. To better reproduce these files in the future, a constant seed was used to recreate these files." with no indication of what the seed was. I got curious and decided to run 'ent' https://www.fourmilab.ch/random/ to see how likely the data in the bad stream was to be random. I used some python to split the…

Now to be fair, such an archive could have been created with a “store” level of compression that doesn’t actually perform any compression.

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

#648

Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.

I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.

they might not have been playing the long con. maybe approached by actors willing to pay them a lot of money to try and slip in a back door. I'm sure a deep dive into code contributions would clear that up for anyone familiar with the code base and some free time.

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

#650
post #98

Earlier quoted context omitted.

So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.

Unrelated: as a dog/pointer lover i really like the term "to bird-dog the problem". Never heard of it (iam from germany though)

I’m from the U.S. and have never heard it either, and don’t understand what it means.
Post reply on HN