Skip to content

Instantly share code, notes, and snippets.

@thesamesam

thesamesam/xz-backdoor.md

Last active March 30, 2024 08:37
Star You must be signed in to star a gist
Save thesamesam/223949d5a074ebc3dce9ee78baad9e27 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. thesamesam revised this gist Mar 30, 2024. 1 changed file with 3 additions and 2 deletions.
    5 changes: 3 additions & 2 deletions xz-backdoor.md
    View file
    @@ -137,8 +137,9 @@ things we know:
    investigating.
    * Vanilla upstream OpenSSH isn't affected unless one of its
    dependencies links `liblzma`.
    * _Update_: Lennart Poettering (via @Foxboron) [mentions](https://news.ycombinator.com/item?id=39867126) that it may happen
    via pam->libselinux->liblzma, and possibly in other cases too.
    <!-- Commented out because I can't actually see where this comes from yet. -->
    <!-- * _Update_: Lennart Poettering (via @Foxboron) [mentions](https://news.ycombinator.com/item?id=39867126) that it may happen
    via pam->libselinux->liblzma, and possibly in other cases too. -->
    * The payload is loaded into `sshd` indirectly. `sshd` is often patched
    to support
    [systemd-notify](https://www.freedesktop.org/software/systemd/man/249/systemd-notify.html)
  2. thesamesam revised this gist Mar 30, 2024. No changes.
  3. thesamesam revised this gist Mar 30, 2024. 1 changed file with 3 additions and 2 deletions.
    5 changes: 3 additions & 2 deletions xz-backdoor.md
    View file
    @@ -136,8 +136,9 @@ things we know:
    * 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`. We are not aware of any cases of this
    in practical production systems.
    dependencies links `liblzma`.
    * _Update_: Lennart Poettering (via @Foxboron) [mentions](https://news.ycombinator.com/item?id=39867126) that it may happen
    via pam->libselinux->liblzma, and possibly in other cases too.
    * The payload is loaded into `sshd` indirectly. `sshd` is often patched
    to support
    [systemd-notify](https://www.freedesktop.org/software/systemd/man/249/systemd-notify.html)
  4. thesamesam revised this gist Mar 30, 2024. No changes.
  5. thesamesam revised this gist Mar 30, 2024. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions xz-backdoor.md
    View file
    @@ -92,8 +92,8 @@ 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 version of `build-to-host.m4` and an explanation of what
    it does:
    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```
  6. thesamesam revised this gist Mar 30, 2024. 1 changed file with 1 addition and 3 deletions.
    4 changes: 1 addition & 3 deletions xz-backdoor.md
    View file
    @@ -131,9 +131,7 @@ things we know:

    * The payload activates if the running program has the process
    name `/usr/sbin/sshd`. Systems that put `sshd` in
    `/usr/bin` or another folder may or may not be vulnerable. This further
    suspects targeting systemd systems due to their [usrmerge](https://wiki.debian.org/UsrMerge)
    initiative putting all binaries in `/usr/bin`.
    `/usr/bin` or 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.
  7. thesamesam revised this gist Mar 30, 2024. 1 changed file with 5 additions and 3 deletions.
    8 changes: 5 additions & 3 deletions xz-backdoor.md
    View file
    @@ -31,9 +31,11 @@ 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 also running a publicly accessible `sshd`, then you are
    likely vulnerable. If you aren't, it is unknown for now, but you should
    update as quickly as possible because investigations are continuing.
    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 `.deb` or `.rpm` based distro with glibc and xz-5.6.0 or xz-5.6.1:
  8. thesamesam revised this gist Mar 30, 2024. 1 changed file with 3 additions and 0 deletions.
    3 changes: 3 additions & 0 deletions xz-backdoor.md
    View file
    @@ -28,6 +28,9 @@ 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 also running a publicly accessible `sshd`, then you are
    likely vulnerable. If you aren't, it is unknown for now, but you should
    update as quickly as possible because investigations are continuing.
  9. thesamesam revised this gist Mar 30, 2024. 1 changed file with 5 additions and 3 deletions.
    8 changes: 5 additions & 3 deletions xz-backdoor.md
    View file
    @@ -33,9 +33,11 @@ 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:
    * .deb or .rpm based distro + glibc + xz-5.6.0 or 5.6.1 and systemd on publicly accessible ssh => update RIGHT NOW NOW NOW
    * .deb or rpm based distro + glibc + xz-5.6.0 or 5.6.1 otherwise => update RIGHT NOW NOW but prioritize the first type
    * glibc + xz-5.6.0 or 5.6.1 otherwise => update RIGHT NOW
    * Using a `.deb` or `.rpm` based 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
  10. thesamesam revised this gist Mar 30, 2024. 1 changed file with 5 additions and 0 deletions.
    5 changes: 5 additions & 0 deletions xz-backdoor.md
    View file
    @@ -32,6 +32,11 @@ If you're also running a publicly accessible `sshd`, then you are
    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:
    * .deb or .rpm based distro + glibc + xz-5.6.0 or 5.6.1 and systemd on publicly accessible ssh => update RIGHT NOW NOW NOW
    * .deb or rpm based distro + glibc + xz-5.6.0 or 5.6.1 otherwise => update RIGHT NOW NOW but prioritize the first type
    * glibc + xz-5.6.0 or 5.6.1 otherwise => update RIGHT NOW

    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
  11. thesamesam revised this gist Mar 30, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -16,7 +16,7 @@ triggerable by remote unprivileged systems connecting to public SSH ports. This
    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.

    TL;DR: We're reasonably sure the following things need to be true for your system
    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)
  12. thesamesam revised this gist Mar 30, 2024. 1 changed file with 2 additions and 3 deletions.
    5 changes: 2 additions & 3 deletions xz-backdoor.md
    View file
    @@ -19,11 +19,10 @@ issues, but we do not know yet what is required to bypass authentication (etc) w
    TL;DR: We're reasonably sure the following things need to be true for your system
    to be vulnerable:

    * You need to be running a rolling-release distro and updating
    religiously
    * 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)
    (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
  13. thesamesam revised this gist Mar 30, 2024. 1 changed file with 5 additions and 1 deletion.
    6 changes: 5 additions & 1 deletion xz-backdoor.md
    View file
    @@ -21,10 +21,14 @@ to be vulnerable:

    * You need to be running a rolling-release distro and updating
    religiously
    * You need to be running a distro that uses glibc and systemd
    * 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)

    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.

    If you're also running a publicly accessible `sshd`, then you are
    likely vulnerable. If you aren't, it is unknown for now, but you should
    update as quickly as possible because investigations are continuing.
  14. thesamesam revised this gist Mar 30, 2024. 1 changed file with 6 additions and 6 deletions.
    12 changes: 6 additions & 6 deletions xz-backdoor.md
    View file
    @@ -114,12 +114,12 @@ If 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 only activates if the running program has the process
    name `/usr/sbin/sshd`. This means that systems that put `sshd` in
    `/usr/bin` or another folder are not vulnerable. This further
    suspects targeting systemd systems due to their
    [usrmerge](https://wiki.debian.org/UsrMerge) initiative putting all
    binaries in `/usr/bin`.
    * The payload activates if the running program has the process
    name `/usr/sbin/sshd`. Systems that put `sshd` in
    `/usr/bin` or another folder may or may not be vulnerable. This further
    suspects targeting systemd systems due to their [usrmerge](https://wiki.debian.org/UsrMerge)
    initiative putting all binaries in `/usr/bin`.
    * 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
  15. thesamesam revised this gist Mar 29, 2024. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions xz-backdoor.md
    View file
    @@ -56,8 +56,8 @@ This backdoor has several components. At a high level:
    consumers don't need to remember how to run autotools and autoconf.
    The version of `build-to-host.m4` in the release tarballs differs
    wildly from the upstream on GitHub.
    * There are crafted test files in the `tests/` folder. These files are
    in the following commits:
    * 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](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0), [74b138d2a6529f2c07729d7c77b1725a8e8b16f1](https://github.com/tukaani-project/xz/commit/74b138d2a6529f2c07729d7c77b1725a8e8b16f1))
    - `tests/files/good-large_compressed.lzma`
    ([cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0),
  16. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -148,7 +148,7 @@ are likely patching their systems too.

    xz-utils has two maintainers:

    * Lasse Collin (_Larzhu_) who has maintained xz since the beginning
    * 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,
  17. thesamesam revised this gist Mar 29, 2024. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion xz-backdoor.md
    View file
    @@ -26,7 +26,8 @@ to be vulnerable:
    (xz-utils provides the library liblzma)

    If you're also running a publicly accessible `sshd`, then you are
    certainly vulnerable. If you aren't, it is unknown for now.
    likely vulnerable. If you aren't, it is unknown for now, but you should
    update as quickly as possible because investigations are continuing.

    If all of these are the case, please update your systems to mitigate
    this threat. For more information about affected systems and how to
  18. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 0 deletions.
    1 change: 1 addition & 0 deletions xz-backdoor.md
    View file
    @@ -159,6 +159,7 @@ get in contact with him.

    ## Misc notes
    * [Please __do not__ use `ldd` on untrusted binaries](https://jmmv.dev/2023/07/ldd-untrusted-binaries.html)
    * [[PATCH] ldd: Do not recommend binutils as the safer option](https://lore.kernel.org/linux-man/20231016061923.105814-1-siddhesh@gotplt.org/t/#u)

    ## Acknowledgements

  19. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -115,7 +115,7 @@ things we know:

    * The payload only activates if the running program has the process
    name `/usr/sbin/sshd`. This means that systems that put `sshd` in
    `/usr/sbin` or another folder are not vulnerable. This further
    `/usr/bin` or another folder are not vulnerable. This further
    suspects targeting systemd systems due to their
    [usrmerge](https://wiki.debian.org/UsrMerge) initiative putting all
    binaries in `/usr/bin`.
  20. thesamesam revised this gist Mar 29, 2024. No changes.
  21. thesamesam revised this gist Mar 29, 2024. 1 changed file with 3 additions and 0 deletions.
    3 changes: 3 additions & 0 deletions xz-backdoor.md
    View file
    @@ -157,6 +157,9 @@ Lasse regularly has internet breaks and is on one at the moment,
    started before this all kicked off. We believe CISA may be trying to
    get in contact with him.

    ## Misc notes
    * [Please __do not__ use `ldd` on untrusted binaries](https://jmmv.dev/2023/07/ldd-untrusted-binaries.html)

    ## Acknowledgements

    * Andres Freund who discovered the issue and reported it to *linux-distros* and then *oss-security*.
  22. thesamesam revised this gist Mar 29, 2024. 1 changed file with 4 additions and 2 deletions.
    6 changes: 4 additions & 2 deletions xz-backdoor.md
    View file
    @@ -16,15 +16,17 @@ triggerable by remote unprivileged systems connecting to public SSH ports. This
    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.

    TL;DR: We _think_ the following things need to be true for your system
    TL;DR: We're reasonably sure the following things need to be true for your system
    to be vulnerable:

    * You need to be running a rolling-release distro and updating
    religiously
    * You need to be running a distro that uses glibc and systemd
    * You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed
    (xz-utils provides the library liblzma)
    * You need to have your SSH port exposed to the public internet

    If you're also running a publicly accessible `sshd`, then you are
    certainly vulnerable. If you aren't, it is unknown for now.

    If all of these are the case, please update your systems to mitigate
    this threat. For more information about affected systems and how to
  23. thesamesam revised this gist Mar 29, 2024. 1 changed file with 2 additions and 2 deletions.
    4 changes: 2 additions & 2 deletions xz-backdoor.md
    View file
    @@ -11,8 +11,8 @@ 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. However, this backdoor is _at least_ triggerable by remote
    unprivileged systems connecting to public SSH ports. This has been
    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.

  24. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -10,7 +10,7 @@ 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 specific
    This backdoor is very indirect and only shows up when a few _known_ specific
    criteria are met. 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
  25. thesamesam revised this gist Mar 29, 2024. 1 changed file with 3 additions and 3 deletions.
    6 changes: 3 additions & 3 deletions xz-backdoor.md
    View file
    @@ -11,10 +11,10 @@ your average Linux or macOS system will have it installed for
    convenience.

    This backdoor is very indirect and only shows up when a few specific
    criteria are met. However, this backdoor is triggerable by remote
    criteria are met. 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, but we do not
    know yet what is required to bypass authentication (etc) with it.
    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.

    TL;DR: We _think_ the following things need to be true for your system
    to be vulnerable:
  26. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -112,7 +112,7 @@ tree. We have not analyzed this payload in detail. Here are the main
    things we know:

    * The payload only activates if the running program has the process
    name `/usr/bin/sshd`. This means that systems that put `sshd` in
    name `/usr/sbin/sshd`. This means that systems that put `sshd` in
    `/usr/sbin` or another folder are not vulnerable. This further
    suspects targeting systemd systems due to their
    [usrmerge](https://wiki.debian.org/UsrMerge) initiative putting all
  27. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -35,7 +35,7 @@ article](https://xeiaso.net/notes/2024/xz-vuln/) or check the
    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
    safter than known unknowns.
    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
  28. thesamesam revised this gist Mar 29, 2024. 1 changed file with 2 additions and 1 deletion.
    3 changes: 2 additions & 1 deletion xz-backdoor.md
    View file
    @@ -13,7 +13,8 @@ convenience.
    This backdoor is very indirect and only shows up when a few specific
    criteria are met. However, this backdoor is triggerable by remote
    unprivileged systems connecting to public SSH ports. This has been
    seen in the wild.
    seen in the wild where it gets activated by connections, but we do not
    know yet what is required to bypass authentication (etc) with it.

    TL;DR: We _think_ the following things need to be true for your system
    to be vulnerable:
  29. thesamesam revised this gist Mar 29, 2024. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion xz-backdoor.md
    View file
    @@ -15,7 +15,7 @@ criteria are met. However, this backdoor is triggerable by remote
    unprivileged systems connecting to public SSH ports. This has been
    seen in the wild.

    TL;DR: We think the following things need to be true for your system
    TL;DR: We _think_ the following things need to be true for your system
    to be vulnerable:

    * You need to be running a rolling-release distro and updating
  30. thesamesam revised this gist Mar 29, 2024. 1 changed file with 146 additions and 46 deletions.
    192 changes: 146 additions & 46 deletions xz-backdoor.md
    View file
    @@ -1,66 +1,166 @@
    # FAQ on the xz-utils backdoor

    There's a lot we don't know. This is a living document - please treat it as such.
    ## Background

    On March 29th, 2024, a backdoor was discovered in
    [xz-utils](https://xz.tukaani.org/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 specific
    criteria are met. However, this backdoor is triggerable by remote
    unprivileged systems connecting to public SSH ports. This has been
    seen in the wild.

    TL;DR: We think the following things need to be true for your system
    to be vulnerable:

    * You need to be running a rolling-release distro and updating
    religiously
    * You need to be running a distro that uses glibc and systemd
    * You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed
    (xz-utils provides the library liblzma)
    * You need to have your SSH port exposed to the public internet

    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](https://xeiaso.net/notes/2024/xz-vuln/) or check the
    [xz-utils page on Repology](https://repology.org/project/xz/versions).

    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
    safter 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.

    ## Design
    * The backdoor has several components:
    - Malicious version of `build-to-host.m4` in the release dist tarballs.
    - Crafted test data in `tests/`
    - 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))
    - tests/files/good-large_compressed.lzma ([cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0), [74b138d2a6529f2c07729d7c77b1725a8e8b16f1](https://github.com/tukaani-project/xz/commit/74b138d2a6529f2c07729d7c77b1725a8e8b16f1))
    - Script called by `build-to-host.m4` after unpacking it from malicious test data which then modifies the build process.
    - IFUNC mechanism, which has legitimate purpose, but exploited to do runtime hooking/redirection
    of e.g. OpenSSH's authentication routines

    * For compromised release tarballs (signed, not auto-generated by github from the git repository),
    a malicious version of `build-to-host.m4` is used to execute a script during the build process.

    * The script, at least in xz-5.6.0 and xz-5.6.1, checks for various conditions like the architecture
    of the machine:
    >```if ! (echo "$build" | grep -Eq "^x86_64" > /dev/null 2>&1) && (echo "$build" | grep -Eq "linux-gnu$" > /dev/null 2>&1);then```
    * ... 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 whether it looks like a .deb or .rpm package is being built:
    > `if test -f "$srcdir/debian/rules" || test "x$RPM_ARCH" = "xx86_64";then`

    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.m4` in the release tarballs differs
    wildly from the upstream on GitHub.
    * There are crafted test files in the `tests/` folder. These files are
    in the following commits:
    - `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))
    - `tests/files/good-large_compressed.lzma`
    ([cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0](https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0),
    [74b138d2a6529f2c07729d7c77b1725a8e8b16f1](https://github.com/tukaani-project/xz/commit/74b138d2a6529f2c07729d7c77b1725a8e8b16f1))
    * A script called by `build-to-host.m4` that 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 version of `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.

    ## Payload

    * The payload is only injected if the backdoor component of the build system, described above, triggered.
    * The runtime payload has __not__ been analysed in detail yet.
    * The payload definitely _at least_ does something if `argv[0] == /usr/bin/sshd`.
    * It might do something in other cases. **We don't know yet!**
    * Vanilla upstream openssh isn't affected unless one of its few dependencies loads _liblzma_. We are not aware of any cases of this.
    * _Patched_ openssh for `systemd-notify` support _is_ affected if systemd is built with _lzma_ support, because `sshd` loads `libsystemd` which loads `liblzma`. Many distributions patch in this support.
    * See https://github.com/openssh/openssh-portable/pull/375.
    * It is known that if it is loaded in openssh's `sshd`, `RSA_public_decrypt` will be redirected into a malicious implementation to bypass authentication.
    If 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 only activates if the running program has the process
    name `/usr/bin/sshd`. This means that systems that put `sshd` in
    `/usr/sbin` or another folder are not vulnerable. This further
    suspects targeting systemd systems due to their
    [usrmerge](https://wiki.debian.org/UsrMerge) initiative putting all
    binaries in `/usr/bin`.
    * 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`. We are not aware of any cases of this
    in practical production systems.
    * The payload is loaded into `sshd` indirectly. `sshd` is often patched
    to support
    [systemd-notify](https://www.freedesktop.org/software/systemd/man/249/systemd-notify.html)
    so that other services can start when sshd is running. `liblzma` is
    loaded because it's depended on by other parts of `libsystemd`. This
    is not the fault of systemd, this is more unfortunate. The patch
    that most distributions use is available here:
    [openssh/openssh-portable#375](https://github.com/openssh/openssh-portable/pull/375).
    * If this payload is loaded in openssh `sshd`, the
    `RSA_public_decrypt` function 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.

    ## People

    I do not want to speculate on people in this document. It is for law enforcement to handle identifying those responsible.
    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 (_Larzhu_) 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. We believe CISA may be trying to get in contact with him.
    * Lasse Collin (_Larzhu_) 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. We believe CISA may be trying to
    get in contact with him.

    ## Acknowledgements

    * Andres Freund ([@anarazel](https://github.com/anarazel)) who discovered the issue and reported it to *linux-distros* and then *oss-security*.
    * 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.

    ## References

    * https://lwn.net/Articles/967180/
    * https://www.openwall.com/lists/oss-security/2024/03/29/4
    * https://www.openwall.com/lists/oss-security/2024/03/29/4