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

231–240 of 1001 posts

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

#231

Post by xyst »

move-on-by wrote: post #87

Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project. > If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released. Reading that in a different light, it says giv…

90 day dark window for maintainers is SOP though. Then after 90 days, it’s free game for public disclosure

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

#232

Post by dralley »

formerly_proven wrote: post #34
AdmiralAsshat wrote: post #19

> Red Hat assigned this issue CVE-2024-3094. Does that mean this affects RHEL and Fedora?

RHEL no, Fedora 41 and Rawhide yes. https://www.redhat.com/en/blog/urgent-security-alert-fedora-... https://lists.debian.org/debian-security-announce/2024/msg00...

Note that Fedora 40 isn't even released yet, it's in beta, Fedora 41 / rawhide is basically a development branch used only by a small number of people.

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

#233

Post by matthews2 »

0x0 wrote: post #67
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

Wow, that's a lot of anonymous accounts adding comments there urging for a fast merge! And this "Hans Jansen" guy is apparently running around salsa.debian.org pushing for more updates in other projects as well: https://salsa.debian.org/users/hjansen/activity

> running around salsa.debian.org pushing for more updates in other projects as well

This is quite common in most (all?) distributions. People are going through lists of outdated packages, updating them, testing them, and pushing them.

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

#234

Post by janc_ »

mrb wrote: post #214
AdmiralAsshat wrote: post #52

Yikes! Do you have any info on the individual's background or possible motivations?

I would presume it's a state actor. Generally in the blackhat world, attackers have very precise targets. They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency who is interested in surveilling, well, everything. Or it co…

Or they have just one or a small number of targets, but don’t want the target(s) to know that they were the only target(s), so they backdoor a large number of victims to “hide in the crowd”.

I agree that this is likely a state actor, or at least a very large & wealthy private actor who can play the long game…

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

#235

Post by iforgotpassword »

poettering wrote: post #163
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…

Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. I…

> And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise.

That's what I think too. Do the relevant docs point this out too? Ages ago they didn't. I think we should try to avoid that people just google "implement systemd notify daemon" and end up on a page that says "link to libsystemd and call sd_notify()".

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

#238

Post by Phenylacetyl »

_lvbh wrote: post #22
yogorenapan wrote: post #6

Very strange behavior from the upstream developers. Possible government involvement? I have a feeling LANG is checked to target servers from particular countries

One thing to note is that the person that added the commits only started contributing around late 2022 and appears to have a Chinese name. Might be required by law to plant the backdoor. That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...

[flagged]

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

#239

Post by o11c »

stefanor wrote: post #177
blcknight wrote: post #158

Earlier quoted context omitted.

> 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

Debian has epochs, but it's a bad idea to use them for this purpose. Two reasons: 1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository. So, the current best practice is the +really+ thing.

Honestly, the Gentoo-style global blacklist (package.mask) to force a downgrade is probably a better approach for cases like this. Epochs only make sense if your upstream is insane and does not follow a consistent numbering system.

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

#240

Post by bodyfour »

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'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).

Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563

I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.

Post reply on HN