WARNING, XZ compression

On my raspberries, both on Bullseye and Bookworm I found /lib/aarch64-linux-gnu/liblzma.so.5

More info can be found here:

I dug deeper, the version on both are below 5.4, so nothing a little less to worry about, I hope.

This is something for rolling-release distros to get on top of. If you’re not using one of those distros, you’re most likely fine. If you are, update your system immediately.

From the final link, you can use the script at https://www.openwall.com/lists/oss-security/2024/03/29/4/3 to see if your system may be vulnerable. Download it locally and read its contents first to make sure you know what it’s going to do (good practice).

Don’t be too quck to dismiss this.
It’s a bit more serious than that, it can be injected anywhere kinda, even at distro level if they for example were using the library when building iso:s.

I got a really good answer here:

But only if you have a compromised version, which as I understand are versions 5.6.0 through 5.6.1. Very few distros had rolled out that those versions to users yet before it was (thankfully) discovered.

1 Like

Let’s hope so, they are still investigating, the github is down and names are being thrown around.

Might be a hack that has been under work for several months, might be more we do not know yet, this is very new discovery and the severity is correctly marked as a 10.

What about applications on snap and flatpak?
Other general applications that might have utilized the library?

We just have to wait and see but absolutely not dismiss such a serous hack (witch it seems to be).

It looks very scary to be sure. Everything I know about the XZ backdoor is quite eye-opening. The person who added this backdoor had been building control and trust over a period of years, with support from multiple sockpuppet accounts applying emotional pressure. To me it smells like a state actor preparing universal vulnerabilities that could be used to impact hundreds of millions of machines in the event of a future conflict.

A sobering reminder to be careful who we trust, be careful who we hand out commit access to, to insist on well-formed commit messages and rigorous code review, and to make sure that important infrastructure has a team behind it, not just a specific person.


I don’t think anyone could have missed those (yet again, disturbing) news. Every Linux distro (+ FreeBSD) is talking about it.

That was my exact first thought too.
It will be interesting investigation to say the least.

My opinion: Linux has become too big, thus the attack surface is simply too big as well. Too many projects and too many things that can go wrong. I wish we had an OS for the PC with less toolkits, a more defined scope, and the core being developed, curated and maintained as a whole, kinda like FreeBSD. (Or Haiku)

Assuming you’re using “Linux” to mean “The FOSS OS ecosystem in general” and not “the Linux kernel specifically” then attacks on common and widely-used libraries are a vulnerability no matter what specific OS you’re using. This is a library that’s everywhere.

Yes that’s what I mean of course, the FOSS ecosystem. But from what I read yesterday, xz had basically just one maintainer who had some personal (mental) issues for quite some time and was looking (or was forced) for a long time for someone else to co-maintain it. No one showed up so it was the perfect case for the malicious actor to show up instead. That’s just unacceptable for a library being everywhere as you said. If everyone wasn’t focused on their “own-best” compression method though, in a pretty much “chaotic” ecosystem, and there was a team responsible for an agreed “standard” already, as well as with other “standards” wrapped in a cohesive PC “core” toolkit designed around the typical PC usage everyone expects (office applications, gaming, mutlimedia), this would probably never happen. Instead we have all those eyes looking at other directions as at how to build yet another of the 700+ distros, yet another package manager, yet another “containerized” solution that does things different etc., leaving the crucial and substantial “core” systems to… pure luck, collectively assigning it to Mr. nobody who will show up by himself somewhere from the… universe, then running in panic 5 minutes before midnight as we realize there’s no-one.

All these “bad things” you are describing, are side effects of freedom. Nobody can and will protect you in a jungle, so you need to learn to live in a free (and potentially dangerous) ecosystem.

:+1: I do, but I 'd wish (the above).

/edit Lots of similar (+ more updated) articles since this. A good article which includes insights from a security expert and cryptographer who analyzes the back door, but it’s in german

/added: found this one on Mastodon, made me giggle :sweat_smile:


The issue of library vulnerabilities is real. The Linux kernel itself has tons of eyes on it since it’s commercially important, and user-facing software generally has lots of eyes too. But that middleware layer is under-appreciated, under-funded, and under-exercised. If you dig into the maintainership details for important libraries, you’ll find that a lot that are maintained by corporate engineers from Red Hat, Microsoft, or another big company you’ve heard of, but many by contrast are maintained by the proverbial random person in Nebraska. And teams beat people; that one random person is always a week away from burnout.

A good reminder to minimize our dependency stacks as much as possible, and to learn about the details of those dependencies.


Another reason why dowloading dependencies in a building process sucks. Imagining xz is hosted on crates/npm/pypi and the evil maintainer doesn’t even need to push distro maintainers to update their packages…


@ rockandstone probably meant Linux based Desktop Operating Systems. Linux based Servers have been ‘Too Big’ in server space for a long time… and have been prime targets for at lest as long. So no change there.

1 Like

How one volunteer stopped a backdoor from exposing Linux systems worldwide

How the XZ backdoor works

1 Like

Yeah it’s really scary. It also demonstrates both the strengths and Weaknesses of Open Source Development.

The problem, in this case, is an overworked, and unpaid, developer with personal issues was tricked into giving up control over a project through Social Engineering.