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

651–660 of 1001 posts

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

#651

Post by EasyMark »

snvzz wrote: post #626
formerly_proven wrote: post #132

Earlier quoted context omitted.

I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377... > Thanks to Hans Jansen for the original patch. https://github.com/tukaani-project/xz/pull/53 There were…

>Hans Jansen and Jia Tan Are they really two people conspiring? Unless proven otherwise, it is safe to assume one is just a pseudonym alias of the other.

or possibly just one person acting as two, or a group of people?

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

#653

Post by javajosh »

NotPractical wrote: post #251
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).

>Ironic considering security is often advertised as a feature of rolling release distros.

Security is a feature of rolling release. But supply-chain attacks like this are the exception to the rule.

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

#655

Post by eru »

tw04 wrote: post #631
hangonhn wrote: post #255

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.

For some random server, sure. For a state sponsored attack? Having an embedded exploit you can use when convenient, or better yet an unknown exploit affecting every linux-based system connected to the internet that you can use when war breaks out - that's invaluable.

Yes, but even states have only finite resources, so even for them compromising an account would be cheaper.

(But you are right that a sleeper would be affordable for them.)

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

#656

Post by [deleted] »

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.)

[deleted]

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

#657

Post by cryptonector »

rom1v wrote: post #406
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

Btw, this is not the only project providing a source tarball different from the git repo, for example libusb also does this (and probably others): - https://github.com/libusb/libusb/issues/1468#issuecomment-19... - https://github.com/orgs/community/discussions/6003

It's very common in autoconf codebases because the idea is that you untar and then run `./configure ...` rather than `autoreconf -fi && ./configure ...`. But to do that either you have to commit `./configure` or you have to make a separate tarball (typically with `make dist`). I know because two projects I co-maintain do this.

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

#658

Post by snnn »

rwmj wrote: post #49
agwa wrote: post #18

Earlier quoted context omitted.

Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.

This is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)

I don't think it would help much. I work on machine learning frameworks. A lot of them(and math libraries) rely on just in time compilation. None of us has the time or expertise to inspect JIT-ed assembly code. Not even mentioning that much of the code deliberately read/write out of bound, which is not an issue if you always add some extra bytes at the end of each buffer, which could make most memory sanitizer tools useless. When you run their unit tests, you run the JIT code, then a lot of things could happen. Maybe we should ask all packaging systems splitting their build into compile and test two stages, to ensure that a testing code would not impact the binaries that are going to be published. I would rather to read and analysis the generated code instead of the code that generates it.

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

#659

Post by cryptonector »

bhaak wrote: 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.

https://news.ycombinator.com/item?id=39872062

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

#660

Post by dec0dedab0de »

AeroNotix wrote: post #221
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…

Pure speculation but my guess is a specific state actor ahem is looking for developers innocently working with open source to then strongarm them into doing stuff like this.

Or hiring them to do it for years without telling them why until they need a favor.
Post reply on HN