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

251–260 of 1001 posts

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

#251

Post by NotPractical »

bonyt wrote: 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…

> If you're not on a rolling release distro, your version is probably older.

Ironic considering security is often advertised as a feature of rolling release distros. I suppose in most instances it does provide better security, but there are some advantages to Debian's approach (stable Debian, that is).

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

#252

Post by mardifoufs »

matthews2 wrote: post #233
0x0 wrote: post #67

Earlier quoted context omitted.

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.

That account seems to be a contributor for xz though, you can see him interact a lot with the author of the backdoor on the GitHub repo. Some pull requests seem to be just the two of them discussing and merging stuff (which is normal but looks weird in this context)

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

#253

Post by o11c »

alright2565 wrote: post #111

https://github.com/tukaani-project/tukaani-project.github.io... > Note: GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases. These archives cannot be disabled and should be ignored. The author was thinking ahead! Latest commit hash for this repo: 8a3b5f28d00ebc2c1619c87a8c8975718f12e271

For a long time, there was one legitimately annoying disadvantage to the git-generated tarballs though - they lost tagging information. However, since git 2.32 (released June 2021; presumably available on GitHub by August 2021 when they blogged about it) you can use `$Format:%(describe)$` ... limited to once per repository for performance reasons.

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

#254

Post by markus_zhang »

lpapez wrote: post #20

So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise. I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the bl…

That's the entire point of certification, and any certification at all. Certification does not guarantee performance. Actually, I would always cast a suspect glance to anyone who is FOCUSED on getting certification after certification without any side project.

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

#255

Post by hangonhn »

pfortuny wrote: post #159

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

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.

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

#257

Post by szundi »

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…

How many of people like this one exist?

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

#258

Post by ncr100 »

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…

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.

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

#259

Post by o11c »

q3k wrote: post #14

NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).

Note that NixOS has a unique advantage in that `dlopen` is easier to analyze, but you do have to check for it. A lot of people are looking only at `ldd` and missing that they can be vulnerable at runtime.

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

#260

Post by markus_zhang »

Keeps one wonder how many similar backdoors are there in the wild. What is the best way to execute such a move? This is sophisticated enough, but not good enough to stay unnoticed for a long while. If I were a state actor I'd think about at least 6-12 months.
Post reply on HN