Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

Post reply on HN
Print view View original

101–110 of 1001 posts

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

#101

Post by graemep »

buildbot wrote: post #86
PedroBatista wrote: post #77

Given the recent ( not so recent ) attacks/"bugs" I feel there is a need to do more than the already hard task of investigating and detecting attacks but also to bring IRL consequences to these people. My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both ) Getting pun…

In the article it says CISA was notified - that sounds like it's going to be a federal investigation if nothing else. If I was this person, I wouldn't be in the USA (or any US friendly nation) ASAP.

One of Jia Tan's recent contributions is "Speed up CRC32 calculation on LoongArch" I would guess the odds are that this is not someone in the US.

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

#102

Post by perihelions »

Imagine a more competent backdoor attempt on xz(1)—one that wouldn't have been noticed this quickly. xz is everywhere. They could pull off a "reflections on trusting trust": an xz which selectively modifies a tiny subset of the files it sees, like .tar.xz software tarballs underlying certain build processes. Not source code tarballs (someone might notice)—tarballs distributing pre-compiled binaries.

edit to add: Arch Linux' entire package system used to run on .tar.xz binaries (they switched to Zstd a few years ago [0]).

[0] https://news.ycombinator.com/item?id=19478171 ("Arch Linux propose changing compression method from xz to zstd (archlinux.org)")

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

#103

Post by bennyhill »

agwa wrote: post #8

> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded…

> so now security-critical daemons like openssh have additional dependencies like liblzma

Systemd itself seems security-critical to me. Would removing other dependencies on libsystemd really make a secure system where systemd was compromised through its library?

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

#104

Post by hostyle »

bonyt wrote: post #48

For those panicking, here are some key things to look for, based on the writeup: - A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older. - A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm p…

$ dpkg-query -W liblzma5

liblzma5:amd64 5.4.1-0.2

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

#105

Post by yieldcrv »

rwmj wrote: 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…

I wonder who the target was!

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

#106

Post by nammi »

thesnide wrote: post #45

The discussion to upload it to Debian is interesting on its own https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708

That name jumped out at me, Hans Jansen is the name Dominic Monaghan used when posing as a German interviewer with Elijah Woods. Not that it can't be a real person

https://youtu.be/IfhMILe8C84

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

#107

Post by travem »

jeffbee wrote: post #3

Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.

Interesting, I used https://ossinsight.io/analyze/JiaT75 to identify contributions from the account used by author of the backdoor. It looks like the account made other potentially problematic contributions to other projects.

The disabling of ifunc in this PR against Google's oss-fuzz project maybe one way they tried to prevent this particular backdoor being flagged by that tool? https://github.com/google/oss-fuzz/pull/10667

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

#108

Post by [deleted] »

sslayer wrote: post #71
arp242 wrote: post #47

I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts). Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some…

I would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account

[deleted]

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

#109

Post by cesarb »

rwmj wrote: post #49
agwa wrote: post #18

Earlier quoted context omitted.

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

This is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)

> We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them.

I would go further than that: all files which are in a distributed tarball, but not on the corresponding git repository, should be treated as suspect.

Distributing these generated autotools files is a relic of times when it could not be expected that the target machine would have all the necessary development environment pieces. Nowadays, we should be able to assume that whoever wants to compile the code can also run autoconf/automake/etc to generate the build scripts from their sources.

And other than the autotools output, and perhaps a couple of other tarball build artifacts (like cargo simplifying the Cargo.toml file), there should be no difference between what is distributed and what is on the repository. I recall reading about some project to find the corresponding commit for all Rust crates and compare it with the published crate, though I can't find it right now; I don't know whether there's something similar being done for other ecosystems.

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

#110

Post by pinko »

returningfory2 wrote: post #93

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.

> it's not the same GitHub account as upstream

This is valuable information, and a sign that this may be the tip of an iceberg.

Post reply on HN