Live data from Hacker News

Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com

491–500 of 1001 posts

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

#491
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.

From what I'm understanding it's trying to patch itself into the symbol resolution step of ld.so specifically for libcrypto under systemd on x86_64. Am I misreading the report?

That's a strong indication it's targeting sshd specifically.

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

#492

I think its much more likely this was not a bad actor, given their long history of commits. It's a known fact that China will "recruit" people to operate them. A quote: > They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to…

I think we should seriously consider something like a ts clearance as mandatory for work on core technologies. Many other projects, both open and closed, are probably compromised by foreign agents.

Killing your pipeline for innovation and talent development doesn't make you secure, it makes you fall behind. The Soviet Union found this out the hard way when they made a policy decision to steal chip technology instead of investing in their own people. They were outpaced and the world came to use chips, networks, and software designed by Americans.

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

#493
post #300

I looked at the differences between the GitHub repository and released packages. About 60 files are in a release package that are not in the repo (most are generated files for building) but also some of the .po files have changes. That's devastating. If you don't build your release packages from feeding "git ls-files" into tar, you are doing it wrong.

Why not `git archive`?

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

#494

I think its much more likely this was not a bad actor, given their long history of commits. It's a known fact that China will "recruit" people to operate them. A quote: > They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to…

We detached this subthread from https://news.ycombinator.com/item?id=39867106.

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

#496

I guess that rewriting liblzma in Rust would not have prevented this backdoor. But would have likely increased the confidence in its safety. Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.

The backdoor hinged on hiding things in large shell scripts, obscure C "optimizations", and sanitizer disabling. I'd expect all of those would be a much bigger red flag in the Rust world.

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

#497

Earlier quoted context omitted.

I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.

I find it funny how MFA is treated as if it would make account takeover suddenly impossible. It's just a bit more work, isn't it? And a big loss in convenience. I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.

https://xkcd.com/538/

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

#498

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…

[deleted]

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

#499

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

Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.

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

#500

I think the lesson here for packagers is that binary testdata should not be present while doing the build. It is too easy to hide things in testdata.

Nice idea, but then you just hide the attack in logo.png that gets embedded in the binary. Less useful for libraries, works plenty good for web/desktop/mobile.
Post reply on HN