A back-door into everything
Well, despite the press (!) at this point probably not. Well, not about this specific issue, unless you are exposing a machine (or virtual machine) to the Internet and running a bleeding edge version of your distribution. As to the wider question of whether you should be worried about the concept and future risks - then IMO yes.
What it it?
It hit the news last night (Mar 29, 2024) as a back-door that has been inserted into the “xz” compression library and by implication into the “ssh” package. Although they are still trying to reverse engineer the code it looks like someone has inserted a skeleton “ssh” key into the “ssh” product such that anyone with that skeleton key can gain access to any remote system via ssh.
I’m guessing there will be quite a few tekkies today working at large companies who have been testing bleeding edge distributions online trying to shut down any instances of affected machines / virtual machines.
Which distro’s are at risk?
It looks like the latest / testing versions of many (all?) distro’s might be affected. I’m seeing a number listed on various sites although I’m not able to check directly. Notably Fedora Rawhide (v41), Debian Testing and Debian Unstable, openSUSE Tumbleweed and MicroOS, Kali.
Typically Enterprise versions and stable versions of the various distro’s are not affected.
How do I double check?
So the problem is that if your system is affected, and IF it has been compromised, any check you run on the machine will be inherently unsafe or untrustworthy. That said, for peace of mind on systems that are not in the at-risk category;
$ xz -V
xz (XZ Utils) 5.4.1
liblzma 5.4.1
The affected versions are 5.6.0 and 5.6.1.
What do I do if I have an affected machine?
Well that’s kind of up to you. The “safe” thing to do would be to backup all your “data”, then wipe it. Reinstall it from scratch, preferably using a version of your OS that’s not in the at-risk category, then restore your data. I would say “data and configuration” however your configuration may have been compromised, so …
Then (!), issue new credentials for anything you had set up (SSH keys, GPG keys etc) and retire all the old keys … then look at anything else on the machine which may have given away something you didn’t want to … VPN configs for example.
Big job? As I said, busy day for tekkies … 
Who did it, who found it, and how did it get through?
Well at this point nobody knows, although I’m pretty sure there will be a concerted effort put in to try to find out. My money (with no evidence whatsoever) would be on one of three large governments but ,
Looks like it was found and reported by a Postgres developer, which is kinda going to make him an International hero.
How did it get through, ironically someone found a new attack vector vector in “testing space”. So the next time someone tells you that code security is linked to the amount of test code you write - you can say “yeah, but not always in a good way!”.
The Wider Problem
How do you stop this from happening to exposed services? Well this is the problem, you can’t, other than not to expose the services in the first place, hence some of my previous postings re; the distributed Internet / web 3.0.
References
https://www.cve.org/CVERecord?id=CVE-2024-3094
There is a reasonably comprehensive walk-through of the code and exploit on YouTube here if anyone is interested in how it came about.
malicious backdoor found in ssh libraries
1 post - 1 participant
