Some of you might have come across the current hot topic in Linux world right now.
The compression utility xz was backdoored in the recent versions and that too by one of its developers. He even tried pushing for the backdoored version to be included in the upcoming Ubuntu 24.04 and Fedora 41.
I checked my fully up to date Pop!_OS and it did not include the affected version.
“The resulting malicious build interferes with authentication in sshd via systemd.”
So are only Linux distros with systemd affected?
There are no known exploit cases found so far and the backdoor was in the recent versions of xz which is not included in most Linux distros, except some Rolling release like Arch, Debian Testing etc. And they have already provided updates for this case.
My Pop!_OS is not fully updated (for sentimental reasons - I want to hang on to kernel 6.6.6 
for a bit longer…
but the xz version is 5.4.1 and the backdoor was in 5.6.x and later …
Well, that’s not so bad on the Fedora side, even if it had succeeded. Fedora 41 won’t be out until November. The beta for Fedora 40 was only just released last week.
That was the plan… The attacker seems to be very patient… he even contributed to the project to win the trust of maintainers
This is a pretty good discussion of the xz issue on an episode of the Open Source Security Podcast.
They get silly sometimes and can get annoying at times, but I listen to them quite a bit.
There needs to be legal action.
This event has damaged the reputation of Linux and of all community produced software.
I dunno… the fact that the attempt was ultimately unsuccessful is a pretty positive sign, IMHO. (As well as being a reminder / wake-up call for open-source contributors and maintainers.)
If this was a proprietary product - the developer (e.g. if they were huge like MS, IBM or Oracle) - would probably have sat on their hands and stymied a fix for longer than necessary…
The “community” found this backdoor, and removed it, before it got any major traction… That’s a positive - I agree with @FeRDNYC …
Yes, I think I have to agree with you and @FeRDNYC .
We should promote the positive aspects if this.
Open source does have builtin safeguards.
It is good that it was caught. But it sounds pretty lucky. There was a 400ms (by some accounts) response time regression and that’s what led someone to track down the issue. That could very easily have been missed or let go (bah, 400ms).
It is good, but also scary.
Right, but it wasn’t. Which is pretty amazing. That is some pretty damn closely scrutinized software, if people notice something’s off simply because of a small drop in performance!
I suppose someone could argue, “Oh, but if an exploit had been added that didn’t hurt performance…” (implying it would’ve gone unnoticed). But then I’d want to know where this magical computing platform is, that someone could insert code into a runtime that does $nefarious_evil_deeds without consuming any CPU cycles.
I think I could achieve that by finding some inefficient or redundant code in the original app and replacing it with
malicious code, keeping the number of CPU cycles the same,
and not altering normal function.
It may not be easy in well written code.
It wasn’t all that long ago that some kids at a university got the idea to see if they could sneak some junk code into some Linux Foundation work. They didn’t get away with it, were identified and the entire university was banned from any further contributions. Seems this is becoming a game of “Can I pull one over on Linux?” I agree with FeRDNYC, there should be legal action. The severity of the punishment shouldn’t add up to sterility, but the character certainly needs a few inches chopped off.
Hi all, 
I´ve been looking at the topic for a few days now and I´m still not quite sure about the implications.
The good thing is: my main system (Linux Lite 6.2) isn´t affected:
dpkg -l | grep xz-utils
ii xz-utils 5.2.5-2ubuntu1 amd64 XZ-format compression utilities
Phew. 
But I´m also using Archlinux as a virtual machine in gnome-boxes. So I took a look at it there as well.
As Archlinux is a rolling distro, and due to the fact that I upgrade the system pretty regularly it´s using the version 5.6.1-3 right now:
arch@archlinux ~> pacman -Qi xz
Name : xz
Version : 5.6.1-3
[...]
So this newer version shoulnd´t be affected anymore.
So far so good.
But I was using the Archlinux VM in the (recent) past as well. So a few questions still remain.
Might there have been a time when it had the backdoored version as part of the system? I don´t know.
What could it have done to the system…?
Is there a way of ascertaining that the present state of the system is alright?
Basically there are two ways I access the Archlinux VM:
either by SSH-ing into it (the sandboxed way) from my main system:
firejail ssh arch@192.168.122.243
or via gnome boxes (also the sandboxed way):
firejail gnome-boxes
On occasions I use the shared folder facility provided by gnome-boxes in order to copy files from the host to the guest.
My main concern is: provided there was the backdoored version of xz on the VM at some time, could it have had any impact on the host 
That would be rather unfortunate.
Thanks in advance for your opinions.
Many greetings from Rosika 
P.S.:
Here I found the following description of the issue:
Description:
Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0.
The tarballs included extra .m4 files, which contained instructions for building with automake that did not exist in the repository. These instructions, through a series of complex obfuscations, extract a prebuilt object file from one of the test archives, which is then used to modify specific functions in the code while building the liblzma package.
This issue results in liblzma being used by additional software, like sshd, to provide functionality that will be interpreted by the modified functions.
Impact:
The malicious code path does not exist in the arch version of sshd, as it does not link to liblzma. However, out of an abundance of caution, we advise users to avoid the vulnerable code in their system as it is possible it could be triggered from other, un-identified vectors.
I suppose I lack the expertise for fully grasping the potential consequences. 
I suppose the question is
Do any of your apps (not just sshd) use liblzma. I so they colud have been compromised if exposed to version 5.6.0 or later.
The whole thing seems shadowy. Noone knows if this inserted code did anything. Until they can be more definite,
I am ignoring it.
It would not be easy to move a rolling release back in time.
One has to hope that the fixed newest releases of liblzma will be sufficient.
Hi Neville,
thanks a lot for your opinion.
I guess that wouldn´t be all too easy to find out. Besides I wouldn´t know anymore what apps I was using back thenn…
Yes, I guess so too.
My main concern is the security of my host, of course.
My hope is that runnig the ssh command in the firejail sandbox and (the other scenario) running gnome-boxes in firejail as well will provide sufficient protection for the host.
Thanks again and many greetings from Rosika
Hi Rosika,
That will definitely help, because firejail constrains what a program can do.
you may never have had the offending version of liblzma.
Updates skip versions sometimes, especially if you had long delays between upgrades,
Regards
Neville