On my raspberries, both on Bullseye and Bookworm I found /lib/aarch64-linux-gnu/liblzma.so.5
More info can be found here:
https://lists.debian.org/debian-security-announce/2024/msg00057.html
https://access.redhat.com/security/cve/CVE-2024-3094
https://archlinux.org/news/the-xz-package-has-been-backdoored/
https://www.openwall.com/lists/oss-security/2024/03/29/4
Edit
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:
https://forums.raspberrypi.com/viewtopic.php?p=2208071#p2208067
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.
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.
/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 
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.
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.
I do, but I 'd wish (the 