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

971–980 of 1001 posts

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

#971

Post by 3v1n0 »

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…

IIRC sshd loads libpam only if specifically configured for it. So while it's not wrong, it's also a more edge case for the backdoor to work.

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

#972

Post by Muntzer »

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…

Adding some unreadable binary to the source code is a really dangerous thing to do. We also need tools to quickly detect the addition of indentation symbols that can be easily overlooked.

BYW,I had a classmate who used to play DOTA1(on war3) under this name at the University of Science and Technology of China a long time ago, and this was his first girlfriend name (maybe) . His father was a high-ranking official. Then he joined the parent department of the Internal Security Detachment, a secret service that has gained a lot of power in the last few years. I hope I'm not awake . lol.

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

#973

Post by account42 »

logicziller wrote: post #925
kapouer wrote: post #423

Earlier quoted context omitted.

Github accounts of both xz maintainers have been suspended.

These shouldn't be suspended, and neither should their repositories. People might want to dig through the source code. It's okay if they add a warning on the repository, but suspending _everything_ is a stupid thing to do.

Tools don't read warnings. Of course the information should not be hidden completely but intentionally breaking the download URLs makes sense.

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

#974

Post by account42 »

Jommi wrote: post #277
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…

the account was either sold or stolen

That's pure speculation and there are plenty of hints to the contrary.

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

#975

Post by account42 »

decoy78 wrote: post #459
ncr100 wrote: post #258

Earlier quoted context omitted.

Security Researchers : Is this request-for-private-disclosure + "90-days before public" reasonable? It's a SEVERE issue, to my mind, and 90 days seems too long to me.

imho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln. This isn't a vuln though - this is an attack.

> imho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln.

But why? A year is a ridiculous time for fixing a vulnerability even a minor one. If a vendor is taking that long its because they don't prioritize security at all and are just dragging their feet.

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

#976

Post by account42 »

ldayley wrote: post #317
szundi wrote: post #257

Earlier quoted context omitted.

How many of people like this one exist?

If this question had a reliable (and public) answer then the world would be a very different place! That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing. Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic…

> We, particularly those us who work on critical infrastructure or software

We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility?

We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.

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

#977

Post by landownersubgrp »

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…

It is not good to take into consideration something with any unreadable text instead of the open text of the programme. It should be excluded.

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

#978

Post by account42 »

Bulat_Ziganshin wrote: post #735
AeroNotix wrote: post #221

Earlier quoted context omitted.

Pure speculation but my guess is a specific state actor ahem is looking for developers innocently working with open source to then strongarm them into doing stuff like this.

many people are patriots of their countries. if state agency would approach them proposing to have paid OSS work and help their country to fight terrorism/dictatorships/capitalists/whatever-they-believe, they will feel like killing two birds with one job

While I don't doubt there are people who would gladly do this work for money/patriotism/whatever, adding a backdoor to your own project isn't really reconcilable with the motivations behind wanting to do OSS work.

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

#979

Post by account42 »

jethro_tell wrote: post #142
bawolff wrote: post #80

Earlier quoted context omitted.

I mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off. This is the sort of case where america's over the top hacking laws make sense.

And what law would you use to target someone who wrote some code and posted it for free on the internet that was willingly consumed?

Similar laws we use to prosecute someone who intentionally brought a poisened cake to the potluck.

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

#980

Post by account42 »

nicolas_17 wrote: post #176
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

.deb has epochs too, but I think Debian developers avoid it where possible because 1:5.4.5 is interpreted as newer than anything without a colon, so it would break eg. packages that depend on liblzma >= 5.0, < 6. There may be more common cases that aren't coming to mind now.

Seems like debian is mixing too many things into the package version - version used for deciding on upgrades and abi version for dependencies should be decoupled like it is in modern RPM distros.
Post reply on HN