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

471–480 of 1001 posts

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

#471

Post by lelandbatey »

Bromeo wrote: post #123
returningfory2 wrote: post #93

A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.

I don't want to read too much into it, but the person (supposedly) submitting the PR seems to work at 1Password since December last year, as per his Linkedin. (And his Linkedin page has a link to the Github profile that made the PR).

They're definitely a real person. I know cause that "1Password employee since December" is a person I know IRL and worked with for years at their prior employer. They're not a no-name person or a fake identity just FYI. Please don't be witch hunting; this genuinely looks like an unfortunate case where Jared was merely proactively doing their job by trying to get an externally maintained golang bindings of XZ to the latest version of XZ. Jared's pretty fantastic to work with and is definitely the type of person to be filing PRs on external tools to get them to update dependencies. I think the timing is comically bad, but I can vouch for Jared.

https://github.com/jamespfennell/xz/pull/2

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

#472

Post by stephc_int13 »

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.

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

#474

Post by stabbles »

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…

How about wheels in the python ecosystem

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

#475

Post by api »

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…

I’m surprised there isn’t way more of this stuff. The supply chain is so huge and therefore represents so much surface area.

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

#476

Post by greatjack613 »

lelandbatey wrote: post #471
Bromeo wrote: post #123

Earlier quoted context omitted.

I don't want to read too much into it, but the person (supposedly) submitting the PR seems to work at 1Password since December last year, as per his Linkedin. (And his Linkedin page has a link to the Github profile that made the PR).

They're definitely a real person. I know cause that "1Password employee since December" is a person I know IRL and worked with for years at their prior employer. They're not a no-name person or a fake identity just FYI. Please don't be witch hunting; this genuinely looks like an unfortunate case where Jared was merely proactively doing their job by trying to get an externally maintained golang bindings of XZ to the l…

[flagged]

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

#477

Post by jnxx »

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.

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.

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

#478

Post by anonymous-panda »

stephc_int13 wrote: post #472

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.

Don’t know all the details and rust isn’t immune to a build attack, but stuff like that tends to stand out a lot more I think in a build.rs than it would in some m4 automake soup.

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

#479

Post by hnald »

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…

It's unfortunate that the anti-systemd party lost the war... years ago. But I don't blame systemd, Lennart Pottering or the fanboys (though it would have been so much better if the guy never worked in open source or wasn't such a prolific programmer). I blame Debian and its community for succumbing to this assault on Unix philosophy (again, years ago).

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

#480

Post by mrcus »

dmarto wrote: post #443

Kinda relevant, as I saw few comments about how safer languages are the solution. Here[0] is a very simple example, that shows how easy such supply chain attacks are in Rust; and lets not forget that there was a very large python attack just a few days ago[1]. [0] - https://github.com/c-skills/rust1 [1] - https://checkmarx.com/blog/over-170k-users-affected-by-attac...

I am very concerned about Rust.

Rust’s “decision” to have a very slim standard library has advantages, but it severely amplifies some other issues. In Go, I have to pull in zero dependencies to make an HTTP request. In Rust, pulling reqwest pulls in at least 30 distinct packages (https://lib.rs/crates/reqwest). Date/time, “basic” base64, common hashing or checksums, etc, they all become supply chain vectors.

The Rust ecosystem’s collective refusal to land stable major versions is one of the amplifying issues. “Upgrade fatigue” hits me, at least. “Sure, upgrade ring to 0.17” (which is effectively the 16th major version). And because v0.X versions are usually incompatible, it’s not really possible to opt not to upgrade, because it only takes a short while before some other transitive dependency breaks because you are slow to upgrade. I recently spent a while writing my code to support running multiple versions of the `http` library, for example (which, to be fair, did just land version 1.0). My NATS library (https://lib.rs/crates/async-nats) is at version 34. My transitive base64 dependency is at version 22 (https://lib.rs/crates/base64).

This makes it nearly impossible for me to review these libraries and pin them, because if I pin foo@0.41.7, and bar needs foo@0.42.1, I just get both. bar can’t do =>0.41, because the point of the 0.X series is that it is not backwards compatible. It makes this process so time consuming that I expect people will either just stop (as if they did) reviewing their dependencies, or accept that they might have to reinvent everything from URL parsing to constructing http headers or doing CRC checks.

Combine this with a build- and compile-time system that allows completely arbitrary code execution, which is routinely just a wrapper for stuff like in the zx attack (look at a lot of the low-level libs you inevitably pull in). Sure, the build scripts and the macro system enables stuff like the amazing sqlx library, but said build and macro code is already so hard to read, it really takes proper wizardry to properly understand.

Post reply on HN