Slackware current also seems to be affected (although it don't use systemd, but it doesn't diminish the seriousness of the matter).RedHat on Friday released an "urgent security alert" warning that two versions of a popular data compression library called XZ Utils (previously LZMA Utils) have been backdoored with malicious code designed to allow unauthorized remote access.
The software supply chain compromise, tracked as CVE-2024-3094, has a CVSS score of 10.0, indicating maximum severity. It impacts XZ Utils versions 5.6.0 (released February 24) and 5.6.1 (released March 9).
"Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code," the IBM subsidiary said in an advisory.
"This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library."
Specifically, the nefarious code baked into the code is designed to interfere with the sshd daemon process for SSH (Secure Shell) via the systemd software suite, and potentially enable a threat actor to break sshd authentication and gain unauthorized access to the system remotely "under the right circumstances."
[...]
Evidence shows that the packages are only present in Fedora 41 and Fedora Rawhide, and do not impact Red Hat Enterprise Linux (RHEL), Debian Stable, Amazon Linux, and SUSE Linux Enterprise and Leap.
Out of an abundance of caution, Fedora Linux 40 users have been recommended to downgrade to a 5.4 build. Some of the other Linux distributions impacted by the supply chain attack are below -
Kali Linux (between March 26 and 29)
openSUSE Tumbleweed and openSUSE MicroOS (between March 7 and 28)
Debian testing, unstable, and experimental versions (from 5.5.1alpha-0.1 to 5.6.1-1)
EDIT: I found something like this https://www.openwall.com/lists/oss-secu ... 24/03/29/4
EDIT: I only now noticed this in changelog== Affected Systems ==
The attached de-obfuscated script is invoked first after configure, where it
decides whether to modify the build process to inject the code.
These conditions include targeting only x86-64 linux:
if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then
Building with gcc and the gnu linker
if test "x$GCC" != 'xyes' > /dev/null 2>&1;then
exit 0
fi
if test "x$CC" != 'xgcc' > /dev/null 2>&1;then
exit 0
fi
LDv=$LD" -v"
if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then
exit 0
Running as part of a debian or RPM package build:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then
Particularly the latter is likely aimed at making it harder to reproduce the
issue for investigators.
Due to the working of the injected code (see below), it is likely the backdoor
can only work on glibc based systems.
a/xz-5.6.1-x86_64-2.txz: Rebuilt.
Seems like a good idea to build this from a git pull rather than the signed
release tarballs. :-)
The liblzma in the previous packages were not found to be vulnerable by the
detection script, but I'd rather not carry the bad m4 files in our sources.
Here's a test script for anyone wanting to try it:
if hexdump -ve '1/1 "%.2x"' /lib*/liblzma.so.5 | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 ; then
echo probably vulnerable
else
echo probably not vulnerable
fi