Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

811–820 of 1001 posts

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

#811

Earlier quoted context omitted.

FWIW, it felt intimidating as hell. And I'm fairly established professionally. Not sure what I'd have done earlier in my career (although I'd probably not have found it in the first place).

This story is an incredible testament to how open-source software can self-regulate against threats, and more broadly, it reminds us that we all stand on the shoulders of contributors like you. Thank you!

This is one threat that was discovered, only because the implementer was sloppy.

Think about what various corps and state-level actors have been putting in there.

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

#812

I am not embarrassed to say... is there anything in there that someone who runs a server with ssh needs to know? I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence. If I am keeping stuff up to date, is there anything at all to worry about?

> I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence. From what I've read, there is still lots of unknowns about the scope of the problem. What has been uncovered so far indicates it involves bypassing authentication in SSH. In https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b... , Sam James points out > If…

Thanks, that gist is a really lucid explanation for normal folks.

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

#813
post #352
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…

Focusing on sshd is the wrong approach. The backdoor was in liblzma5. It was discovered to attack sshd, but it very likely had other targets as well. The payload hasn't been analyzed yet, but _almost everything_ links to libzma5. Firefox and Chromium do. Keepassxc does. And it might have made arbitrary changes to your system, so installing the security update might not remove the backdoor.

It checks for argv[0] == "sshd"

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

#814

xz is just a horribly designed format, and always has been. If you use it, please switch to Lzip. Same compression level, but designed by someone competent. https://www.nongnu.org/lzip/ https://www.nongnu.org/lzip/xz_inadequate.html

Thanks for that link, lzip sounds useful

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

#815

Incredible. It's like discovering your colleague for 2 years at the secret nuclear weapon facility is a spy for another country, covering his tracks until the very last minute. Feels like a Hollywood movie is coming up. Should we start doing background checks on all committers to such critical IT infrastructure?

But how? Let's say you're one of 10 maintainers of an open source project. A new user wants to contribute. What do you do? Do you ask them to send you some form of ID? Assuming this is legal and assuming you could ensure the new user is the actual owner of an actual, non counterfeit ID, what do you do? Do you vet people based on their nationality? If so, what nationality should be blackballed? Maybe 3 maintainers are American, 5 are European and 2 are Chinese. Who gets to decide? Or do you decide based on the company they work for?

Open source is, by definition, open. The PR/merge request process is generally meant to accept or refuse commits based on the content (which is why you have a diff), not on the owner.

Building consensus on which commits are actually valid, even in the face of malicious actors, is a notoriously difficult problem. Byzantine fault tolerance can be achieved with a 2/3 + 1 majority, but if anyone can create new identities and have them join the system (Sybil attack) you're going to have to do things differently.

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

#816

This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that. A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and d…

Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg).

Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.

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

#817
post #816

This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that. A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and d…

Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg). Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunt…

You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.

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

#820
post #477

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

And, Joey Hess has counted at least 750 commits to xz from that handle. https://hachyderm.io/@joeyh/112180715824680521 This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.

I have some questions.

1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!

2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.

Post reply on HN