- cross-posted to:
- sysadmin@lemmy.world
- privacy@lemmy.ml
- cross-posted to:
- sysadmin@lemmy.world
- privacy@lemmy.ml
The malicious changes were submitted by JiaT75, one of the two main xz Utils developers with years of contributions to the project.
“Given the activity over several weeks, the committer is either directly involved or there was some quite severe compromise of their system,” an official with distributor OpenWall wrote in an advisory. “Unfortunately the latter looks like the less likely explanation, given they communicated on various lists about the ‘fixes’” provided in recent updates. Those updates and fixes can be found here, here, here, and here.
On Thursday, someone using the developer’s name took to a developer site for Ubuntu to ask that the backdoored version 5.6.1 be incorporated into production versions because it fixed bugs that caused a tool known as Valgrind to malfunction.
“This could break build scripts and test pipelines that expect specific output from Valgrind in order to pass,” the person warned, from an account that was created the same day.
One of maintainers for Fedora said Friday that the same developer approached them in recent weeks to ask that Fedora 40, a beta release, incorporate one of the backdoored utility versions.
“We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added),” the Ubuntu maintainer said.
He has been part of the xz project for two years, adding all sorts of binary test files, and with this level of sophistication, we would be suspicious of even older versions of xz until proven otherwise.
Shots fired!
It seems WSL Ubuntu and Kali are safe with versions 5.2.5 and 5.4.4 installed respectfully.
Damn, I installed mine disrespectful.
I thought about the same (disrespectful) as I typed it. I’ve already laughed with you!
Is that when you install it in a VM, as if to show it that it’s not a good enough little distro to boot directly on your hardware?
I suddenly feel so guilty!
Don’t forget about openSUSE Tumbleweed! It’s actually affected AFAIK.
I think the AI that wrote the article misunderstood.
Arch doesn’t build from release tar balls, but straight from git. Arch also doesn’t link sshd against liblzma. So while they’ve shipped the dirty version of xz utils, at least sshd is not affected.
It’s possible that the dirty version affected some of the other things that link liblzma. Like a handful of kde components for example.
The linked article is by Dan Goodin from Ars Technica. He’s not immune to mistakes, but he’s been writing good articles about security for years.
Can we please not accuse everybody of being AI just because they made a mistake?
Suspicious. /s
Well, he’s credited as the editor overseeing security stuff. Reading between the lines I’d say he’s just taking responsibility for the articles correctness.
This article in particular is just so poorly written that you’d forgive me for assuming it wasn’t man-written.
Arch didn’t build from git until March 28th. See commit history for xz and lib32-xz packages.
https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad
https://gitlab.archlinux.org/archlinux/packaging/packages/lib32-xz/-/commit/9d411814d763dfaba969c4c16adc0ce9a131bb2e
Also, the malicious code only activated if it detected being built as dpkg or rpm.