MX Linux Forum

I've been following the recent flurry of news on the critical+ vulnerability in xz-utils, and it seems like the affected version (xz-utils V5.6.0, V5.6.1) hasn't made it into MX23 at this time. Furthermore, it looks like the version of openssh-server that's provided with MX23 doesn't link in xz-utils, and of course the default MX23 install doesn't install systemd.

As if I needed another reason to be thrilled that I'm running MX on _all_ my desktop Linux installs! Kudos to the dev team for making sensible choices.

the affected xz packages are newer upstream versions. Since Debian Stable doesn't have the cutting edge versions, we don't have those packages. It's not that MX did anything special.

And MX does have systemd packages installed. It is just that the MX default is to boot into sysvinit. People can choose to boot into systemd if they want.

It's not that MX did anything special.

Nope, but these are some of the benefits of running on top of Debian Stable...

As @asqwerth pointed out, only the newer upstream versions were affected (trixie/sid). Debian has since reverted back to the 5.4.5 version.

https://security-tracker.debian.org/tra ... -2024-3094


I like the name they gave the updated package. hehehe

siamhie wrote: Sat Mar 30, 2024 11:30 am I like the name they gave the updated package. hehehe

That's actually part of the debian rules - a necessary rollback needs a higher version so it will update but with +really<version> to indicate this has been done. I've had to label packages that way a couple times over the years.

PhilSalkie wrote: Sat Mar 30, 2024 10:00 am I've been following the recent flurry of news on the critical+ vulnerability in xz-utils, and it seems like the affected version (xz-utils V5.6.0, V5.6.1) hasn't made it into MX23 at this time. Furthermore, it looks like the version of openssh-server that's provided with MX23 doesn't link in xz-utils, and of course the default MX23 install doesn't install systemd.

It's not that simple...

* MX stable is built on top of Debian stable, but there is also an MX testing repo, and there are also beta repositories

* try "ldd /usr/sbin/sshd | grep 'lzma|systemd' " and you will see that the MX sshd (just like the Debian sshd) actually links to liblzma (which is how the payload gets injected) and also to libsystemd. This is because Debian *patched* upstream OpenSSH to better integrate with Lennart Pottering's monstrosity (but that's another can of worms I won't get into). Upstream OpenSSH has no such dependencies.

* now, Debian stable (and thus MX stable) indeed have liblzma 5.4.1. But if you look at the Debian discussion (https://bugs.debian.org/cgi-bin/bugrepo ... ug=1068024), they're thinking about reverting to 5.3.1, which is the version before this Jia Tan got involved (he had commits before gaining maintainership, and he also "helped" the previous maintainer / original author, Lasse Collin, "off-list" before that).

Finally, there are arguments that XZ is also a bit of another monster in the Linux ecosystem, regardless of the recent backdoor. Have a look at some of the poor design and implementation choices (https://www.nongnu.org/lzip/xz_inadequate.html). That document is by the author of lzip, who seems to have gotten a bad rep over the years, probably for some very valid reasons (but then again everyone who ever argued against systemd has also been accused of FUD and whatnot by the systemd camp).

A couple of interesting articles about this:

First, debian decided to postpone the 12.6 release until the devs had had a chance to do an in-depth analysis of CVE effects.
https://linuxiac.com/debian-decided-to- ... 6-release/

Second, OpenSUSE Timbleweed just rebuild the entire code base and pushed 2000+ updates out!
https://linuxiac.com/tumbleweed-users-f ... e-updates/

Frmald, thanks for the insight on using ldd - I just looked at the dependencies of the openssh-server package, which doesn't seem to require, recommend, or suggest the xz package (didn't happen to have openssh-server installed on this machine to dig deeper.) Totally agree that patching openSSH to add functionality for systemd is a nightmare - this kind of thing is exactly why systemd shouldn't exist in the first place (at least not in its many-tentacled monolithic form.)

Also thinking wistfully of the days of statically linked system core binaries which aren't vulnerable to library preload attacks and can have their checksums compared against a master manifest.

Also also thinking of Ken Thompson's paper on Trusting Trust, this exploit has very much that feel to it, inserting itself into the binary without changing the source code (but in this case it's the build scripts that are malevolent, not the compiler.)

PhilSalkie wrote: Wed Apr 03, 2024 8:48 pm thinking of Ken Thompson's paper on Trusting Trust

Amen!