undefined | Better HN

0 pointstheteapot1mo ago0 comments

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only.

Here's the quote from the guy that discovered it in the initial public disclosure [1]:

  After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer. The upstream xz repository and the xz tarballs have been backdoored. At first I thought this was a compromise of debian's package, but it turns out to be upstream. One portion of the backdoor is *solely in the distributed tarballs* and debian's import of the tarball ... it is also present in the tarballs for 5.6.0 and 5.6.1.

[1]: https://www.openwall.com/lists/oss-security/2024/03/29/4

0 comments

3 comments · 1 top-level

dvogel1mo ago· 2 in thread

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have yet to see a reproducible build project that includes such cross-build checks.

theteapotOP1mo ago

> Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise.

Good. Then we are on the same page.

uecker1mo ago

Nowadays you would work in git and then you would be able to easily detect any discrepancy between the upstream tar ball and the upstream source imported via git. But yes, better support for securing more of the process is needed.

j / k navigate · click thread line to collapse