The xz-utils backdoor has been removed | Hacker News Reader

The xz-utils backdoor has been removed

github.com

56 pointsEveryPizza21 comments

This commit message is gold: https://github.com/tukaani-project/xz/commit/e93e13c8b3bec92...

    While the backdoor was inactive (and thus harmless) without inserting
    a small trigger code into the build system when the source package was
    created, it's good to remove this anyway:

      - The executable payloads were embedded as binary blobs in
        the test files. This was a blatant violation of the
        Debian Free Software Guidelines.

      - On machines that see lots bots poking at the SSH port, the backdoor
        noticeably increased CPU load, resulting in degraded user experience
        and thus overwhelmingly negative user feedback.

      - The maintainer who added the backdoor has disappeared.

      - Backdoors are bad for security.

https://github.com/tukaani-project/xz/commit/780cbf29d5a88db... to update the NEWS file is equally honest:

    5.6.1 (2024-03-09)

    IMPORTANT: This fixed bugs in the backdoor (CVE-2024-3094) (someone
    had forgot to run Valgrind).

https://github.com/tukaani-project/xz/commit/77a294d98a9d2d4...

    Special author: Jia Tan was a co-maintainer in 2022-2024. He and
    the team behind him inserted a backdoor (CVE-2024-3094) into
    XZ Utils 5.6.0 and 5.6.1 releases. He suddenly disappeared when
    this was discovered.

Violation of the Debian Free Software guidelines? Is that a problem?

The owner of github became a money making machine using a business model violating the same guidelines.

It was a joke.

This has to go on the list of "best understatements ever", along with that famous captain's announcement when an ash cloud knocked out all four engines.

I would really really really like to see all commits by Jia Tan reverted, not only those currently found to be malicious.

Debian and NixOS (and other distros) are already downgrading or discussing to downgrade to versions without those commits.

I think that making a 5.4 or 5.6 release without any of those commits (with stuff reimplemented as needed) would assuage most concerns

Who would do that? The project lacking active contributors is what enabled Jai Tan to get away with it in the first place.

Can’t we migrate to other libraries?

At least in Debian there's already the inevitable discussion about a supposed opportunity for "finally" moving to zstd. Which to me, frankly, feels a bit like getting out of the frying pan and into the fire, or what I think Arch (yuck) did years ago. That's not because I'm so much into xz. It's kind of funny there's a possible Debian connection, of all things, considering that quite a lot authorities and services in areas like China, Russia or Iran are recently migrating, for obvious reasons, from Windows/Mac to more or less home-made (~styled) Linux distributions, that just often happen to be based on Debian. I don't think this is too popular in English speaking countries in particular, but then I really didn't want to chime in on the speculations. ;P

Where is this discussion happening?

None of these suggestions actually cover the part where someone or someones do a bunch of bloody work.

Again, this is the problem in the first place.

There is a reimplementation of xz here at least https://github.com/gendx/lzma-rs

> This commit message is gold

It's really sad to see commit messages like this, downplaying the issue. It's also concerning to see libsystemd get a free pass.

How did they get a free pass?

Systemd's ridiculous inability to manage daemons correctly, like every other init system on the planet, necessitated debian, redhat, and others patching ssh, just so systemd could reliably start ssh.

Which is what enabled this vulnerability to be viable.

I'm relieved that the GitHub repo has finally been restored. I was just about to make a commit to fix our liblzma dependency, which would have required a vcpkg overlay to use a different upstream repo.

The security policy was also updated: https://github.com/tukaani-project/xz/commit/780d2c236de0e47...

Maybe we need an international NGO/co-op to provide essential services for small, essential FOSS projects such as security comms, security audits, build infrastructure, testing, best practices, background investigations, and so forth.

The "one guy's little piece of code holding up the world" is a SPOF and much easier to attack than if they had some help and automation.

"security comms, security audits, build infrastructure, testing, best practices, background investigations, and so forth."

Typical over-engineering that comes from large corporations.

They will turn FOSS into a walled garden, as if contributing to projects was not a pain already.

> They will turn FOSS into a walled garden, as if contributing to projects was not a pain already.

The only thing in here that has potential negative impact are the background investigations, but it might be reasonable to have an independent third party that offers this as a service for project leads.

Reply on news.ycombinator.com