Do not run xz --version. Instead check the version in your package manager.
this post was submitted on 30 Mar 2024
73 points (98.7% liked)
technology
23218 readers
2 users here now
On the road to fully automated luxury gay space communism.
Spreading Linux propaganda since 2020
- Ways to run Microsoft/Adobe and more on Linux
- The Ultimate FOSS Guide For Android
- Great libre software on Windows
- Hey you, the lib still using Chrome. Read this post!
Rules:
- 1. Obviously abide by the sitewide code of conduct. Bigotry will be met with an immediate ban
- 2. This community is about technology. Offtopic is permitted as long as it is kept in the comment sections
- 3. Although this is not /c/libre, FOSS related posting is tolerated, and even welcome in the case of effort posts
- 4. We believe technology should be liberating. As such, avoid promoting proprietary and/or bourgeois technology
- 5. Explanatory posts to correct the potential mistakes a comrade made in a post of their own are allowed, as long as they remain respectful
- 6. No crypto (Bitcoin, NFT, etc.) speculation, unless it is purely informative and not too cringe
- 7. Absolutely no tech bro shit. If you have a good opinion of Silicon Valley billionaires please manifest yourself so we can ban you.
founded 5 years ago
MODERATORS
debian/ubuntu based distros:
apt show xz-utils
or
dpkg -l | grep xz
redhat/fedora-based:
yum info xz
dnf info xz
arch-based:
pacman -Qi xz
EDIT: correction as suggested below
On my machine the package name is slightly different:
apt show xz-utils
5.4.1, my habit of putting off updates pays off again
Why is that? I know the latter gives you more info, but it's still the same thing isn't it?
Because you are running the affected software. It's a bad idea to run something if we are aware that it contains or relies on malicious code.
Omg obviously. Can't believe I didn't realize that. Thanks for the answer.
Wow! This was so close to perhaps being one of the worst security compromises in open source history.
For me I feel like we have not had any big security stuff since the whole log4j thing. While this seems bigger they have caught it relatively early. I feel like more people had to panic patch Minecraft servers with log4j.
maybe the libwebp vulnerability deserves a honorable mention, although i don’t think it has had as big an impact, it could’ve been way worse.
Good point! I did forget about that one.
My only reservation is that this compromised contributor has been working on the project for a few years. I hope that this is the end of the tunnel and there aren’t more issues to be uncovered with further analysis.
Its easy to spiral out of control thinking about how the practice that got us this backdoor is something that is used all over the open source community to build code. In the end we can only evaluate what is in front of us and pray the things lurking in the shadows are something we can deal with when they expose themselves.
Jokes on you; I haven't run a system update since 2006
Ubuntu 6.06 moment (Debian 3.1)
I'm using arch btw. ... oh no
Mods should sticky this. This is the third post in this comm about the vulnerability.
The only people who will have this vulnerability AFAIK (and have it be actionable with the ssh backdoor) are folks running Debian unstable on a ssh server. The shitty part about this is a rupture in trust for the maintainers at xz.
Honestly, the attacker picked a really shitty time frame considering their payload isn't in any important point releases where they could have the most effect.
How to check your version without running xz on nixOS, the official OS of trans people:
ls -l $(which xz)
I'm at 5.4.4 thankfully.
My repos are only pulling 5.4.1 
Phew. Same.
So, what do we do in this case to avoid contamination via updating? Just don't "sudo apt upgrade" for a while?
I'm no expert, but I'd assume the repository maintainers would pull the malicious packages ASAP. check to see if you have any updates available, if the malicious version is not available then you're chilling 
So I assume the malicious code is being removed and a version 5.6.2 without it will be released soon? Or is it more complex to solve and I’m being naive?
So the backdoor was not in the source code but in the system used to build the code. Devs for a long time now have swapped over to an automated build system and what happened with this one is in the last step for the xz build process it adds the backdoor to it. You simply have to remove the references to the data in the build config.
EDIT: Rewrote a sentence that sounded stupid
Something like that. It should be patched shortly. Thank god for smart people and autists.
Does it spread itself to other parts of the system, or it contained exclusively within locations used by this program?
People aren't 100% sure yet but preliminary analysis believes it is contained. Look forward to excrutiatingly-detailed levels of analysis to be published in the coming days and weeks, this is like every Foss Discourse topic tossed into a blender all at once.
goddamn chuds hijacking my linux libraries
Good thing I disassembled my laptop this week.
Haven't updated since last month, is this a newly released vulnerability?