# PSA: backdoor in xz-utils and relevance for the Julia ecosystem

**URL:** <https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328>\
**Category:** Community\
**Tags:** security, binarybuilder, yggdrasil\
**Created:** [March 30, 2024, 12:31pm UTC](https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328 "2024-03-30T12:31:01Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [March 30, 2024, 12:31pm UTC](https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328/1 "2024-03-30T12:31:01Z")

</div>

## Statement of the problem

A [thread in oss-security](https://www.openwall.com/lists/oss-security/2024/03/29/4) mailing list reported that the [XZ Utils](https://en.wikipedia.org/wiki/XZ_Utils) project was affected by a [backdoor](https://en.wikipedia.org/wiki/Backdoor_(computing)): one of the current maintainers of the project appeared to have injected malicious code, included in versions v5.6.0 and v5.6.1 of the xz-utils package, that under certain circumstances could potentially compromise an OpenSSH client and obtain login credentials to remote systems.

## Affected systems and conditions for the backdoor to work

XZ Utils is somewhat popular in Linux distributions. Quoting from the [XZ Utils Wikipedia article](https://en.wikipedia.org/w/index.php?title=XZ_Utils&oldid=1216316376#Supply_chain_attack):

> The malicious mechanism consists of:
> 
> 1. Two test files that contain the malicious binary code. These files are available in the git repository, but remains dormant unless extracted and injected into the program.[[16]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-SamJames-16) The code uses the [glibc](https://en.wikipedia.org/wiki/Glibc) IFUNC mechanism to replace an existing function in [OpenSSH](https://en.wikipedia.org/wiki/OpenSSH) called `RSA_public_decrypt` with a malicious version. OpenSSH normally does not load liblzma, but a common third-party [patch](https://en.wikipedia.org/wiki/Patch_(computing)) used by several Linux distributions cause it to load [libsystemd](https://en.wikipedia.org/wiki/Systemd), which in turn loads lzma.[[16]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-SamJames-16)
> 2. A modified version of `build-to-host.m4`, which extracts a script that performs the actual injection. The modified m4 file is _not_ present in the git reponsitory; it is only available from [tar files](https://en.wikipedia.org/wiki/Tar_file) released by the maintainer separate from git.[[16]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-SamJames-16)
> 3. A script that extracts the malicious code from “test case” files and injects them into `liblzma`. The file appears to only perform the injection when the system being built on (1) is an [x86-64](https://en.wikipedia.org/wiki/X86-64) Linux system (2) uses glibc and [GCC](https://en.wikipedia.org/wiki/GNU_Compiler_Collection) (3) is being built via [dpkg](https://en.wikipedia.org/wiki/Dpkg) or [rpm](https://en.wikipedia.org/wiki/RPM_Package_Manager).[[16]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-SamJames-16)
> 
> It is unknown whether this backdoor was intentionally placed by a maintainer or whether a maintainer was compromised.[[17]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-17)
> 
> The list of affected Linux distributions includes [Debian unstable](https://en.wikipedia.org/wiki/Debian)[[18]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-18), [Arch Linux](https://en.wikipedia.org/wiki/Arch_Linux)[[19]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-19), [Fedora Rawhide](https://en.wikipedia.org/wiki/Fedora_Rawhide)[[20]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-20), [Kali Linux](https://en.wikipedia.org/wiki/Kali_Linux)[[21]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-21), [OpenSUSE Tumbleweed](https://en.wikipedia.org/wiki/OpenSUSE_Tumbleweed)[[22]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-:0-22). Confirmed to not be affected are [Red Hat Enterprise Linux](https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux)[[23]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-23), [SUSE Linux Enterprise](https://en.wikipedia.org/wiki/SUSE_Linux_Enterprise)[[22]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-:0-22), [Amazon Linux](https://en.wikipedia.org/wiki/Amazon_Linux)[[24]](https://en.wikipedia.org/wiki/XZ_Utils#cite_note-24).

If you use one of the affected systems, you may want to update your system as soon as possible, to make sure you get your version of xz-utils downgraded to a version not currently known to be affected by any backdoors.

As detailed in the oss-security thread, the backdoor is installed in the liblzma library only when several conditions are met:

1. the target system is x86\_64-linux-gnu (Linux kernel, on x86\_64 architecture, using glibc as standard C library)
2. the compiler is GCC
3. the build system detects dpkg or rpm are being used

Then, when the liblzma library contains the malicious payload, the exploit works only when all the following conditions are met:

1. the `TERM` environment variable is not set
2. the name of the executable (the `argv[0]` argument inside the program) needs to be `/usr/sbin/sshd`
3. the environment variables `LD_DEBUG`, `LD_PROFILE` are not set
4. the environment variable `LANG` needs to be set

## Relevance for the Julia ecosystem

You may know that in the Julia ecosystem we ship pre-built binaries for several packages written in C/C++, Fortran, Rust, Go, by using the [BinaryBuilder](https://binarybuilder.org/) framework. We also happen to provide builds of xz-utils, in the form of the [`XZ_jll`](https://github.com/JuliaBinaryWrappers/XZ_jll.jl) package. We have builds for both the affected versions, v5.6.0 and v5.6.1. However, BinaryBuilder does not meet condition 3 (building through dpkg or rpm) to activate the backdoor during compilation. The announcement of the security exploit in the oss-security mailing list includes a script to detect whether a build of liblzma is vulnerable, by checking a certain pattern is present in the hexadecimal dump of the library. I personally verified our builds of `liblzma.so` in `XZ_jll` v5.6.0 and v5.6.1 do _not_ contain the known pattern. I know other people have independently carried out the same test, I encourage you to do the same if you’re still suspicious.

Furthermore, it is highly unlikely any user meets condition 2 for actually being vulnerable to the exploit: the executable `/usr/sbin/sshd` in user’s systems will most likely _not_ link to our builds of `liblzma.so` (which, as stated in the previous paragraph, does not appear to be affected by the security threat), but rather to a build of `liblzma.so` provided by the operating system, _if_ linking to `liblzma.so` at all.

To summarise, _ **to the best of our knowledge we do not believe our builds of the XZ Utils package in the form of the `XZ_jll` package are subject to any disclosed security vulnerability** _.

## Measures taken in the Julia ecosystem to reduce the impact of the vulnerability

That said, out of an abundance of caution, we immediately [yanked versions 5.6.0 and 5.6.1 of XZ\_jll from the General registry](https://github.com/JuliaRegistries/General/pull/103876), as soon as we were made aware of the security threat by @semarie on Slack. If you now try to install or update `XZ_jll` from the General registry you will only get versions up to v5.4.6, which at the moment are not known to actively carry security vulnerability. And again, even if you happen to have installed `XZ_jll` v5.6.0 or v5.6.1 during last month we do not expect this to have concretely posed a security threat for your system. But remember that if you use one of the affected systems mentioned above, you may be vulnerable through the packages provided by your operating system.

We will continue to monitor the situation, if it will become apparent that also previous versions of XZ Utils may have included security vulnerabilities we will yank also them from the General registry.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [April 1, 2024, 5:03am UTC](https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328/2 "2024-04-01T05:03:08Z")

</div>

Looking at the [Debian](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024) and [Gentoo](https://bugs.gentoo.org/928134#c26) discussions, there is some thought to reverting further back to eliminate or minimize the exposure to the author, Jia Tan, whose account was used introduce the backdoor.

XZ uses even minor versions for stable releases and odd minor versions for development releases.

XZ version 5.2.5 has no commits from the offending account:  
[https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.5](https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.5)

XZ version 5.2.6 is the first version where the offending account begins “contributing”:  
[https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.6](https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.6)

Version 5.2.5 does have a security advisory though: [ZDI-22-619](https://www.zerodayinitiative.com/advisories/ZDI-22-619/) / [CVE-2022-1271](https://www.cve.org/CVERecord?id=CVE-2022-1271).

To that end I have created a pull request for another xz version 5.2.5 with the above CVE [patched](https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html):

> <https://github.com/JuliaPackaging/Yggdrasil/pull/8396>
>
> \# XZ version 5.2.5 with ZDI-22-619 patch (This pull request)
> XZ v5.2.5 contains… no commits from apparent backdoor author Jia Tan
> https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.5
> 
> \## Security patches 
> We apply patch to cover CVE-2022-1271, ZDI-22-619, ZDI-CAN-16587
> https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html
> https://www.zerodayinitiative.com/advisories/ZDI-22-619/
> https://www.cve.org/CVERecord?id=CVE-2022-1271
> 
> \## Comparison to Debian and Ubuntu releases
> 
> This is the version in Debian bullseye (oldstable)
> https://sources.debian.org/src/xz-utils/5.2.5-2.1~deb11u1/
> This is also the version in Ubuntu 22.04LTS jammy (5.2.5-2ubuntu1)
> https://packages.ubuntu.com/jammy/xz-utils
> The new patch is also included in the Debian patch set:
> https://sources.debian.org/src/xz-utils/5.2.5-2.1~deb11u1/debian/patches/0010-xzgrep-Fix-escaping-of-malicious-filenames-ZDI-CAN-1.patch/
> 
> See the ongoing Debian discussion in the incident bug report:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024
> 
> \# XZ v5.2.6 (Next stable version, first with Jia Tan)
> 
> XZ v5.2.6 contains three commits from Jia Tan
> https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.6
> Commits:
> https://git.tukaani.org/?p=xz.git;a=commit;h=e20ce2b12251a246c50fb5b7fa2204c11611b407
> https://git.tukaani.org/?p=xz.git;a=commit;h=749b86c2c18ab61a07f19ec8fefc67325da97397
> https://git.tukaani.org/?p=xz.git;a=commit;h=76a5a752b8467ff591dd028deb61e9bf2c274c7e
> Jia Tan is added to AUTHORS here:
> https://git.tukaani.org/?p=xz.git;a=commit;h=692de534fae6c38f92416793addcf5f60ffe2bf6
> Conda-forge is currently locked to v5.2.6 since they yanked v5.2.9
> https://anaconda.org/conda-forge/xz/files
> https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/548

If merged, I think it will create XZ\_jll.jl v5.2.5+3.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [April 2, 2024, 8:18pm UTC](https://discourse.julialang.org/t/psa-backdoor-in-xz-utils-and-relevance-for-the-julia-ecosystem/112328/3 "2024-04-02T20:18:26Z")

</div>

# Specify version 5.2.5 to obtain a “Jia Tan” free version of XZ

XZ\_jll.jl 5.2.5+3 has been released. This version [contains no commits from Jia Tan](https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.2.5) and includes a [patch](https://www.mail-archive.com/xz-devel@tukaani.org/msg00551.html) for [CVE-2022-1271](https://www.cve.org/CVERecord?id=CVE-2022-1271).

The `v5.2.5` tag and the patch have been [checked against Lasse Collin’s public key](https://github.com/JuliaPackaging/Yggdrasil/blob/108e784907a3131fe521fa8a01b91cd163b814ef/X/XZ/build_tarballs.jl#L29-L35).

> **[Release XZ-v5.2.5+3 · JuliaBinaryWrappers/XZ\_jll.jl](https://github.com/JuliaBinaryWrappers/XZ_jll.jl/releases/tag/XZ-v5.2.5%2B3)**
>
> Contribute to JuliaBinaryWrappers/XZ\_jll.jl development by creating an account on GitHub.

To install, I recommend the following procedure.

```julia
] add XZ_jll@5.2.5
pin XZ_jll

```

Equivalently,

```Julia
using Pkg
Pkg.add(name="XZ_jll", version=v"5.2.5+3")
Pkg.pin(name="XZ_jll", version=v"5.2.5+3")

```

# The default XZ\_jll version is 5.4.6, signed by Jia Tan

Installing XZ\_jll without specifying a version will install [version 5.4.6 of XZ](https://git.tukaani.org/?p=xz.git;a=shortlog;h=refs/tags/v5.4.6). The `v5.4.6` tag was [signed by Jia Tan](https://git.tukaani.org/?p=xz.git;a=tag;h=416121610f2357dddb155a4fb898c4184b7085a2), the apparent author of the backdoor, on January 26th, 2024. At the time of this writing, there are no _known_ vulnerabilities in version 5.4.6.

```julia-auto
(@v1.10) pkg> activate --temp
  Activating new project at `/tmp/jl_pcjWcT`

(jl_pcjWcT) pkg> add XZ_jll
    Updating registry at `~/.julia/registries/General.toml`
   Resolving package versions...
    Updating `/tmp/jl_pcjWcT/Project.toml`
  [ffd25f8a] + XZ_jll v5.4.6+0

```

To obtain version 5.2.5 **not** signed by Jia Tan, you must specify version `5.2.5`:

```julia-auto
(jl_YD86jd) pkg> add XZ_jll@5.2.5
   Resolving package versions...
   Installed XZ_jll ─ v5.2.5+3
    Updating `/tmp/jl_YD86jd/Project.toml`
⌃ [ffd25f8a] + XZ_jll v5.2.5+3

```