51

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?

2

5 Answers 5

34

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'.)

9
  • When I read launchpad.net/ubuntu/+source/xz-utils/+publishinghistory it looks like it did make into the release pocket of noble, not merely the proposed pocket. Commented Mar 31 at 4:19
  • @PeterGreen I'm not sure exactly how to read that page, but the multiple entries under "release" for 5.6.0 don't seem to list any "published" dates. The CVE tracker page has a comment that "The affected version of xz-utils was only in noble-proposed, and was removed before migrating to noble itself."
    – IMSoP
    Commented Mar 31 at 19:18
  • 2
    @PeterGreen It was in Proposed. It was never actually in the release of Noble itself (always focus on the pocket it was in!). The version that shows now is 5.6.1+really5.4.5-... which is actually 5.4.5 again.
    – Thomas Ward
    Commented Apr 1 at 16:14
  • 1
    So Noble will soon get updates that will only use the "proven" and "good" code? I wanted to be a Ubuntu bug locator and upgraded to 24.04. Can I hope that the xz will be removed (or fixed) soon? Commented Apr 5 at 2:57
  • 1
    @JohnCarter That's already been fixed. The same day as my post. There is no vulnerable xz anymore in Noble. And as a precaution, every binary package in Noble is being rebuilt currently.
    – Thomas Ward
    Commented Apr 5 at 16:11
24

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.

2
14

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

update

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-utils

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

5
  • IOW - yes. when looking at supply chain attacks it's not desirable to declare the testing release out of scope. someone put this backdoor in place and not just for the lulz. it's is wonderful it got caught so quickly, but whatever whoever, they likely already reached their goal. Commented Mar 30 at 16:00
  • @userunknown now that your answer is undeleted, would you please consider adding an all around safe to run command? This way everyone can be happy and your answer useful without any doubt. Thank you! :) Commented Apr 12 at 9:21
  • @BeastOfCaerbannog: As far as all around safe commands exist, I added the one I know of. Thanks for your differentiated support in Meta. Please check whether it fits your high standards and makes you happy. ;) I have some doubt, that it will in every aspect, but I couldn't avoid, rejecting the apt-cache advice you gave. I had to double down, as muru would call it. ;) Commented Apr 12 at 21:56
  • 1
    The original report of the issue contains a nice and safe approach for testing: hexdump -ve '1/1 "%.2x"' "$(ldd $(which sshd) | grep liblzma | grep -o '/[^ ]*')" | grep -q f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410 && echo "is infected" || echo "not infected".
    – terdon
    Commented Apr 13 at 13:06
  • @terdon: according to my manpage for ldd Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code., but from the previous paragraph, this only applies in some circumstances. However, I guess almost all linux distributions depend on systemd, and systemd is already linked to liblzma, and hundreds of other programs too, so what do you win by invoking it one time less? Nothing. Commented Apr 13 at 16:27
4

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.

3

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
2
  • thanks for actually posting which packages to check!
    – xealits
    Commented Apr 3 at 13:38
  • @userunknown thanks for letting me know about pgrep! I think ps also links to it (see askubuntu.com/a/1483215/158442) so that should be avoided too. So if the system is suspected to have the compromised version installed, it is best to shut it down immediately and use a known safe live USB to inspect it instead!
    – muru
    Commented Apr 13 at 17:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .