Moderator Note: This question relates to a rapidly evolving current event. It has been protected to prevent unrelated banter or answers that do not benefit the post.
In March 2024, a backdoor was discovered in libxz 5.6.0 and 5.6.1.
Does this vulnerability affect Ubuntu LTS or any other Ubuntu release?
As a member of the Community Council and as an Ubuntu Developer myself, I reached out to Debian and Ubuntu security contacts.
LTS and currently stable releases of Ubuntu do not have versions of xz that are affected by this, so existing Ubuntu releases are unaffected.
The impacted xz versions were only in noble-proposed which impacts only the in-development release. No versions of xz in already-released versions of Ubuntu are affected.
The in-development release, Noble 24.04, is currently being deep-dived and scoured for whether there is any lasting effect, and both Debian and Ubuntu reverted the packaging to a known-good older xz release that does NOT contain revisions from the malicious actor.
The Ubuntu Security Team is still tracking this, though no impact exists on current stable releases (Noble is not yet released at the time of this post, so it is not considered 'stable'.)
Answer: No.
Reasoning:
Edit: On the 30th of March, it got added to Ubuntu CVE
Recap of the results on that page:
trusty Not vulnerable
xenial Not vulnerable
bionic Not vulnerable
focal Not vulnerable (5.2.4-1ubuntu1.1)
jammy Not vulnerable (5.2.5-2ubuntu1)
mantic Not vulnerable (5.4.1-0.2)
upstream Needs triage
Highest version we have is 5.4.5
noble (libs): XZ-format compression library
5.4.5-0.3: amd64 arm64 armhf i386 ppc64el riscv64 s390x
Publication Date: 2024/03/29 12:30 PM PST
CVE Identifier: CVE-2024-3094
AWS is aware of CVE-2024-3094, which affects versions 5.6.0 and 5.6.1 of the xz-utils package. This issue may attempt to introduce security issues in openssh through the use of liblzma within some operating system environments. Amazon Linux customers are not affected by this issue, and no action is required. AWS infrastructure and services do not utilize the affected software and are not impacted. Users of Bottlerocket are not affected.
Customers using other operating systems are advised to refer to information provided by the OS vendor to address any concerns originating from this reported issue.
No.
If you're using some other Linux flavor or a prerelease, or to verify by yourself, issue on the command line:
xz --version
xz (XZ Utils) 5.2.5
liblzma 5.2.5
(this is a xUbuntu 22.04, updated yesterday).
According to this site: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma)
… (to be affected by the backdoor.)
So you can test your installation with the above command.
According to Canonical, only testing versions (24.04) might be affected.
Source: https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Some people advise not to run xz from the command line at all. They're arguing, AFAIK, that a maliciously crafted program, which tries to open a backdoor in sshd when run by systemd, is suspicious of having additional bad side effects, which is a legitimate concern to have, if we think of something made to vandalize a system. I don't agree with these concerns, but let us get this out of the way:
Of course it is perfectly fine to check for the version of xz in a different way. Recommended has been, by @Quasimodo,
strings -a $(which xz) (in a different fashion, not recommended for untrustworthy files)This is fine. Go for it, if you have the slightest doubts, xz could contain additional attack vectors.
I don't.
My reasoning is: A) This is not a virus, which spreads itself by running it. It is a high impact, very well crafted backdoor, hidden in binary test files which should be spread by the distributions themselves and a lot of effort has gone into gaining enough trust to do so. A second attack vector would have increased the chances of getting detected, especially in a small and trivial code segments, which reports a version number and is easy to understand in a diff.
B) If people are running test releases in production, they are already at high risk. You shouldn't do it. If they had it running for some days, and you still assume that there is another issue, it is already too late. Well - there might be some admins, which only start sshd occasionally and haven't done so, since installing the updated, backdoor providing version of liblzma. And from these admins, some might take their advice from AU. Fine.
C) But isn't liblzma everywhere, even in the kernel? I heard so! What does it mean, everywhere? It's surely a gross exaggeration, isn't it?
Let's do some investigation. Don't believe rumors.
for f in /bin/* /sbin/*
do
ldd $f 2>/dev/null | grep -q liblzma.so && echo $f
done | wc -l
What number do you expect? How many programs?
3, 30, 300?
I get 614.
Ironically, one suggestion has been, to use
apt-cache policy xz-utilsfor testing. Unfortunately, apt-cache is dynamically linked to liblzma, too - as stated, over 600 files on my system. As is systemctl, journalctl, systemd and a few variants of systemd, so if you really think, there is a second attack vector, it is far too late.
So no, I'm not convinced at all, that issuing xz --version increases your risk an iota. Therefore I will not revoke my recommendation to use it.
Some guy on the internet has used it, and it reported the correct version of the malicious program. No other observations were reported.
If you have reason to suspect that you might have a system with a compromised release installed, take it offline immediately. As noted in other answers, many executables link directly or indirectly (e.g., via libsystemd which the known backdoor tries to exploit) to liblzma. While you may be lucky and services might not have been reloaded after the compromised version was installed, and so would still be using the old version of the library, don't take an unnecessary risk and allow it more chances to reveal something new.
Instead, as I said above, take it offline, and use a live USB on the system, or, attach the disk to another system, with a known-safe OS, mount the compromised partitions noexec to prevent accidental execution of anything in it, and then inspect the package database or package management logs. I'd avoid touching xz or liblzma itself.
Note that some are working on de-JiaTan-ed versions of xz, removing every change they made, while trying to retain other contributions, as any of those changes might be laying groundwork for more exploits. Joey Hess, a long-time Debian Developer, and one of those people, says:
I stress that I have not found such a security hole, I'm only considering what the worst case possibilities are. I think we need to fully consider them in order to decide how to fully wrap up this mess.
Whether such stealthy security holes have been introduced into xz by "Jia Tan" or not, there are definitely indications that the ssh backdoor was not the end of what they had planned.
[…]
My impression is that all of this was well planned and they were in it for the long haul. They had no reason to stop with backdooring ssh, except for the risk of additional exposure. But they decided to take that risk, with the sandbox disabling. So they planned to do more, and every commit by "Jia Tan", and really every commit that they could have influenced needs to be distrusted.
This is why I've suggested to Debian that they revert to an earlier version of xz. That would be my advice to anyone distributing xz.
That's how much responsible people are distrusting anything touched by this attacker. Some distributors like Homebrew have already rolled back to the last version before the attacker made their first commit. Thankfully, it seems no currently supported version of Ubuntu has anything touched by "Jia Tan". But if you're on a test release — and there are many reasonable reasons for that (to think of one case that might be of value to an attacker: maybe you're working for a Canonical partner doing QA and so have access to confidential information) — or another disro like Fedora Rawhide, just take the system offline as soon as you can.
For a quick check, run the commands below to get an overview of the machine's information. Focus mainly on versions of the xz and liblzma libraries that must be less than or equal to 5.5.*.
uname -a
lsb_release -a
ldd --version
apt list --installed | grep liblzma
sudo lsof -p $(ps -aux | grep '[s]shd.*listener' | awk '{print $2}') | grep 'liblzma.so'
This last command will show if there is an SSH server loading the liblzma library, where you can confirm which version is loaded into memory.
See the output of the above commands on an Ubuntu Server system:
$ uname -a
Linux ts132.saphetor.com 5.15.0-101-generic #111-Ubuntu SMP Tue Mar 5 20:16:58 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
Release: 22.04
Codename: jammy
$ ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.6) 2.35
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
$ apt list --installed 2>/dev/null| grep liblzma
liblzma-dev/jammy,now 5.2.5-2ubuntu1 amd64 [installed]
liblzma5/jammy,now 5.2.5-2ubuntu1 amd64 [installed]
$ sudo lsof -p $(ps -aux | grep '[s]shd.*listener' | awk '{print $2}') | grep 'liblzma.so'
sshd 1595 root mem REG 252,2 170456 632762 /usr/lib/x86_64-linux-gnu/liblzma.so.5.2.5
