Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

151–160 of 1001 posts

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

#151
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…

I did notice that my debian-based system got noticeably slower and unresponsive at times the last two weeks, without obvious reasons. Could it be related? I read through the report, but what wasn't directly clear to me was: what does the exploit actually do? My normal internet connection has such an appalling upload that I don't think anything relevant could be uploaded. But I will change my ssh keys asap.

> I did notice that my debian-based system got noticeably slower and unresponsive at times the last two weeks, without obvious reasons. Could it be related?

Possible but unlikely.

> I read through the report, but what wasn't directly clear to me was: what does the exploit actually do?

It injects code that runs early during sshd connection establishment. Likely allowing remote code execution if you know the right magic to send to the server.

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

#152
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…

Every single commit this person ever did should immediately be rolled back in all projects.

It's weird and disturbing that this isn't the default perspective.

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

#153
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…

[flagged]

Don't blame the guy. Could have happened to anyone. Even you.

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

#154
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…

Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.

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

#155
post #36
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…

That is all the protocol is. From https://www.freedesktop.org/software/systemd/man/latest/sd_n... : > These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable. The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like: const char *addrstr = getenv("NOTIFY_SOCKET"); if (addrstr) { int fd =…

goddamnit leftpad got us too :)

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

#157
@people who write github scanners for updates and security issues (dependabot and the like)

Can we start including a blacklist of emails and names of contributors (with reasons/links to discussions)?

I can't track them and I don't want them in my projects.

Might not be very helpful as it is easy to create new identities, but I see no reason to make it easier for them. Also, I might approach differently someone with lots of contributions to known projects than a new account, so it still helps.

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

#158
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…

> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade.

I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html

Post reply on HN