Unit 6: Processes and services · Lesson 6 of 6 · 20 min

Case file: the xz backdoor

A compression library almost became a way into every SSH server. Check what sshd loads and which machines got the bad version.

mission

You are
You are answering a question from security on 29 March 2024: are we affected?
Situation
A backdoor shipped in xz and liblzma 5.6.0 and 5.6.1 could reach sshd on systems that link liblzma through libsystemd.
Goal
Check web01 itself, then the fleet inventory.
Hand in
Affected hosts and the evidence.

case file

xz Utils Backdoor

xz Utils open source project · 2024

On March 29, 2024, engineer Andres Freund disclosed that xz/liblzma versions 5.6.0 and 5.6.1 contained a backdoor (CVE-2024-3094) that could affect sshd on Linux systems where sshd links liblzma through libsystemd. He noticed it while investigating SSH logins using unusual CPU and valgrind errors on test systems. The malicious build step existed only in the release tarballs, not in the git repository, and was introduced by a project committer; it was caught before reaching most stable distributions.

What went wrong

A long-trusted contributor to an under-resourced project inserted obfuscated code, with part of it present only in release tarballs that differed from the source repository.

What would have stopped it

  • Build packages from the source repository (or verify release tarballs match the tagged source) instead of trusting maintainer-generated tarballs.
  • Use reproducible builds and diff release artifacts against source to catch injected build scripts.
  • Stage new upstream versions in testing/rolling channels with performance and behavior monitoring before promoting to stable.
  • Support and review critical open source dependencies (maintainer health, multiple reviewers).

What defenders could have seen

  • Performance regressions such as sshd authentication taking noticeably more CPU/time.
  • Memory-checker (valgrind) errors appearing in a library after an upgrade.
  • Inventory query showing xz/liblzma 5.6.0 or 5.6.1 installed.

sourcesseclists.orgcisa.gov

How a library reaches sshd

  1. sshdThe SSH server, running as root
  2. libsystemdLinked on some distributions for service notifications
  3. liblzmaPulled in by libsystemd, where the backdoor lived
01

What does sshd load?

ldd lists the shared libraries a program loads.

learner@root-lab
ldd /usr/sbin/sshd | awk '{print $1}' | head -n 8
linux-vdso.so.1
libcrypt.so.1
libwrap.so.0
libaudit.so.1
libpam.so.0
libselinux.so.1
libgssapi_krb5.so.2
libkrb5.so.3
ldd /usr/sbin/sshd | grep -c lzma
0

you should see On this Ubuntu build, sshd does not load liblzma at all.

02

Which version is installed?

Read the full Debian version string, not just the first number.

learner@root-lab
dpkg -l liblzma5 | tail -n 1
ii  liblzma5:amd64 5.6.1+really5.4.5-1 amd64        XZ-format compression library
xz --version
xz (XZ Utils) 5.4.5
liblzma 5.4.5

you should see 5.6.1+really5.4.5-1: the package number says 5.6.1, but the code inside is 5.4.5.

defender tip Distributions roll back with names like +really so package managers still see an upgrade. Always confirm with the program's own version.

03

Check the fleet

learner@root-lab
cat fleet-packages.csv
host,distro,package,version
web01,ubuntu-24.04,liblzma5,5.6.1+really5.4.5-1
db01,debian-12,liblzma5,5.4.1-0.2
ci-runner-03,debian-unstable,liblzma5,5.6.1-1
build-07,fedora-40-beta,xz-libs,5.6.0-1.fc40
backup01,ubuntu-22.04,liblzma5,5.2.5-2ubuntu1
dev-riya,ubuntu-24.04,liblzma5,5.6.1+really5.4.5-1
monitor01,rocky-9,xz-libs,5.2.5-8.el9_0
awk -F, '$4 ~ /^5\.6\.[01]/ && $4 !~ /really/ {print $1, $2, $4}' fleet-packages.csv
ci-runner-03 debian-unstable 5.6.1-1
build-07 fedora-40-beta 5.6.0-1.fc40

you should see Two hosts run a real 5.6.0 or 5.6.1, both on fast-moving distributions.

Reading a version

First number only
liblzma5 5.6.1+really5.4.5-1
=> affected?

A false alarm wastes a night

Whole string, then the binary
dpkg: 5.6.1+really5.4.5-1
xz --version: 5.4.5
=> not affected

Evidence you can put in the report

What a defender takes away

  1. 1Know what each critical process loads.
  2. 2Read the full package version, then the program's own.
  3. 3Rolling and beta distributions get both fixes and backdoors first.

Questions

0 of 3 solved

Answer each one from what you find on your lab machine.