XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access
-
Ouch!
-
it seems that, just like me, a lot of users got that malicious code..
[myuser@eos ~]$ cat /var/log/pacman.log | grep xz [2023-08-25T19:29:44-0300] [ALPM] installed xz (5.4.4-1) [2023-11-04T08:53:29-0300] [ALPM] upgraded xz (5.4.4-1 -> 5.4.5-1) [2024-01-27T04:33:49-0300] [ALPM] upgraded xz (5.4.5-1 -> 5.4.6-1) [2024-02-26T07:51:11-0300] [ALPM] upgraded xz (5.4.6-1 -> 5.6.0-1) [2024-03-11T08:25:38-0300] [ALPM] upgraded xz (5.6.0-1 -> 5.6.1-1) [2024-03-28T22:21:55-0300] [ALPM] upgraded xz (5.6.1-1 -> 5.6.1-2)
I don't leave any service that I don't use enabled, so sshd.service was disabled.. This is definitely a good thing to do, disable what you don't use..
-
@mcury
Actually, not upgrading might be the most prudent thing to do, at least till you check what version your system is proposing to update to. IIUC, the exploit had only gotten into bleeding-edge distros so far, and not for very long even there. So if you were a little behind on your updates you might've avoided downloading the malicious code. You don't want to go from there to having it installed, if your distro hasn't finished pushing out the fixed version. -
@tgl said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
@mcury
Actually, not upgrading might be the most prudent thing to do, at least till you check what version your system is proposing to update to. IIUC, the exploit had only gotten into bleeding-edge distros so far, and not for very long even there. So if you were a little behind on your updates you might've avoided downloading the malicious code. You don't want to go from there to having it installed, if your distro hasn't finished pushing out the fixed version.I use EndeavourOS which is Arch based, so, it is updated on a daily basis..
Based on what I've been reading so far, these two versions 5.6.0-1 and 5.6.1-1 were affected..
5.6.1-2 is fixed.That guy, if I'm not mistaken, was there for around two years building reputation..
That was pretty nasty to say the least. -
@mcury said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
That guy, if I'm not mistaken, was there for around two years building reputation..
That was pretty nasty to say the least.Yeah, that indeed is scary. You have to wonder about moles playing equally long games in other projects. I'm assuming this guy was funded by a nation-state's intelligence apparatus, because who else is going to put in that kind of effort? (Or else his account was broken into, but people seem to think not.)
-
Writeup in Ars
https://apple.news/A9xzZKmgVSQOqWrHZsotu-Q -
@tgl said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
I'm assuming this guy was funded by a nation-state's intelligence apparatus, because who else is going to put in that kind of effort? (Or else his account was broken into, but people seem to think not.)
That is the question I'm asking myself right now
-
@SteveITS said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
Writeup in Ars
https://apple.news/A9xzZKmgVSQOqWrHZsotu-Qhm, so Fedora decided to revert to the 5.4.x versions of xz Utils ? That was a different approach than Arch did.
I'm not sure if that is going to be enough.https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2
-
That is something to think about, this guy wasn't shooting randomly..
-
@mcury “He has been part of the xz project for 2 years”
Seems very fortunate it was caught before hitting production Linux releases. Though it sounds like MacOS packages were using it.
-
a little history:
got this link from EnOS forum:
https://boehs.org/node/everything-i-know-about-the-xz-backdoor -
the github repo has been disabled...
nice
-
@mcury said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
hm, so Fedora decided to revert to the 5.4.x versions of xz Utils ? That was a different approach than Arch did.
I'm not following? The discussion you linked showed Arch doing exactly the same thing.
It's surely not unreasonable to worry about every version signed by the compromised developer (and I'm confident there are people putting 5.4.x under a microscope right now). My bet though is that the pre-5.6 versions don't actually contain anything dangerous. The developer showed his hand by pushing for 5.6 to be spread rapidly, as he'd not done for the earlier releases.
-
There's enough pain to go around here!
-
@tgl said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
The developer showed his hand by pushing for 5.6 to be spread rapidly, as he'd not done for the earlier releases.
This is huge, the FOSS community will take time to recover and I think things are going to change permanently from now on..
I'm trying to look at it in a different perspective and not witch hunt as mentioned here in this threadbig blow to the stomach that this was.
-
I hope pfSense is not affected, 2.7.2 show:
xz --version xz (XZ Utils) 5.4.4 liblzma 5.4.4
As far as i can follow the bug report on Debian [1] it's still not clear revert to 5.4.5 is enough since the
last version of a trusted person was 5.4.1.[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024#72
-
In my own personal opinion it's unlikely because this exploit targeted specific Linux distros. sshd with a patch for systemd integration which obviously doesn't apply to FreeBSD.
However that's only the known exploit. Whist nothing in known in other versions we are monitoring the situation closely.
-
@stephenw10 said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
However that's only the known exploit. Whist nothing in known in other versions we are monitoring the situation closely.
They are evaluating libarchive now, there are commits from the same developer.
What haunts me is that we don't know how deep this going to go.. -
@mcury said in XZ Struck By Malicious Code That Could Allow Unauthorized Remote System Access:
What haunts me is that we don't know how deep this going to go..
Yes, I'm afraid that's not the end of the story, this has the potential for a really nightmare.
But at the moment we can only monitoring the situation as @stephenw10 said. -
A couple months ago I was testing openVPN and I could see my IP traverse the firewall however after I disconnected something else was connected a IP address from digital oceans IP block, I have logging enabled on the firewall and you could see the enumeration occurring so I killed the state and only allow VPN connections from specific IP addresses. Think about eternal blue, they patch it but the bug reappears over and over. Cyber security teams need to stay one step ahead of abuses.