Xz/liblzma 10/10 CVE scored

There is a 10/10 CVE scored backdoor vulnerability in the xz-utils package, affecting versions 5.6.0+. This is still a developing situation, and further reversions may be necessary as the extent of commits by the offending individual are being reviewed still. Other vulnerabilities may be discovered along the way in other packages.

Libranext 4.0 alpha 3.2 and earlier: unaffected by this backdoor, according to current information (they’re shipped with 5.4.4 if fully updated).

Libranext 4.0 alpha 4: is affected and I’m working on addressing this. If you have access to an alpha 4 chroot image, please discontinue use immediately and wait for further information.

Debian stable systems: Unaffected, according to current information

For more information:

https://www.cve.org/CVERecord?id=CVE-2024-3094

https://www.openwall.com/lists/oss-security/2024/03/29/4

An update on the situation, as it pertains to Libranext:

Libranext 4.0 alpha4 uses the backdoored version of xz in it’s temporary toolchain used to cross-compile from scratch. Having seen newer information, including extracted strings from the backdoor, it seems that the backdoor shouldn’t have been activated on a Libranext system as alpha4 does not have dpkg or rpm, and currently doesn’t have SSH built yet. However, I’m not sure if it being built in the tempchain on the alpha3.2 host could trigger the backdoor, as alpha3.2 has ssh present (and running), as well as dpkg, and both are theoretically present during the tempchain build as we’re not in the cross-compiled environment at that point in the build. To be safe, I’m going to nuke the current alpha4 image I’ve been working off of and rebuild.

That being said, there is discussion about how far back prior to the backdoor’d release that we’d have to go to escape commits known to be done by the malicious actor. Any commits by them are undergoing scrutiny across multiple open-source packages, which brings me to the next point: libarchive. alpha4 uses libarchive’s bsdtar by default, instead of GNU tar. libarchive is currently reverting/rewriting patches submitted by Jia Tan (the presumed bad actor). The release of libarchive used in alpha4 is likely impacted.

In short:

  • Need to figure out how far back we have to go in xz releases to get to a likely safe version, and then backport security fixes that we know will be needed if we go back as far as some are suggesting
  • Need to pick up the new libarchive commits to remove potential flaws
  • Unfortunately, need to completely rebuild alpha4 because the tempchain also includes a potentially backdoored xz, that may have been triggered by the host system

Mostly for my reference, but also valuable information:

https://bugs.gentoo.org/928134

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024