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

201–210 of 1001 posts

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

#201

Post by intel_brain »

stefanor wrote: post #177
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

Debian has epochs, but it's a bad idea to use them for this purpose. Two reasons: 1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository. So, the current best practice is the +really+ thing.

Got this on OpenSUSE: `5.6.1.revertto5.4-3.2`

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

#203

Post by multimoon »

It seems like based on the (very well written) analysis that this is a way to bypass ssh auth, not something that phones out which would've been even scarier.

My server runs arch w/ a LTS kernel (which sounds dumb on the surface, but was by far the easiest way to do ZFS on Linux that wasn't Ubuntu) and it seems that since I don't have SSH exposed to the outside internet for good reason, and my understanding is Arch never patched shhd to begin with that I and most people who would be in similar situations to me are unaffected.

Still insane that this happened to begin with, and I feel bad for the Archlinux maintainers who are now going to feel more pressure to try to catch things like this.

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

#204

Post by wpietri »

AdmiralAsshat wrote: post #52

Yikes! Do you have any info on the individual's background or possible motivations?

I get why people are focusing on this bad actor. But the question that interests me more: how many other apparent individuals fit the profile that this person presented before caught?

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

#205

Post by LVB »

arp242 wrote: post #137
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.

As a bit of an aside, I would never accept a PR like this, and would always update $large_vendored_dependency myself. This is unreviewable, and trivial to insert any backdoor (unless you go through the motions of updating it yourself and diffing, at which point the PR becomes superfluous). I'd be wary even from a well-known author unless I knew them personally on some level (real-life or via internet). Not that I wou…

The (most?) popular SQLite driver for Go often gets PRs to update the SQLite C amalgamation, which the owner politely declines (and I appreciate him for that stance, and for taking on the maintenance burden it brings).

e.g., https://github.com/mattn/go-sqlite3/pull/1042#issuecomment-1...

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

#207

Post by bombcar »

londons_explore wrote: post #175
aidenn0 wrote: post #98

Earlier quoted context omitted.

So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.

Which is why a really good backdoor is a one line logic bug somewhere which is fiendishly difficult to trigger.

http://underhanded-c.org if people want examples of what could (and probably, somewhere, IS) being done.

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

#208

Post by londons_explore »

tetromino_ wrote: post #69
asveikau wrote: post #10

That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.

A big part of the problem is all the tooling around git (like the default github UI) which hides diffs for binary files like these pseudo-"test" files. Makes them an ideal place to hide exploit data since comparatively few people would bother opening a hex editor manually.

testdata should not be on the same machine as the build is done. testdata (and tests generally) aren't as well audited, and therefore shouldn't be allowed to leak into the finished product.

Sure - you want to test stuff, but that can be done with a special "test build" in it's own VM.

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

#209

Post by joeyh »

perihelions wrote: post #102

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…

A backdoored xz could also run payloads hidden inside other xz files, allowing targeted attacks.

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

#210

Post by bonzini »

ptx wrote: post #168
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…

Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code. (This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)

Yes, it's usually regenerated already. However even the source is often pretty gnarly.

And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code.

This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.

Post reply on HN