LinuxQuestions.org - xz backdoored.

- Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)

- - xz backdoored. (https://www.linuxquestions.org/questions/linux-security-4/xz-backdoored-4175735467/)

Also a topic in the Slackware forum, thanks for the links.

Sorry, I did not see that. I did look in the News forum.

Nothing to be sorry about!

That thread is Slackware specific, so another in Security for all comers seems fine. The more info the better!

Arch, Manjaro, Debian SID, and other cutting edge distributions already have the fixed libraries.

It will be in the security and backport set of more conservative distributions shortly.

Quote:

Originally Posted by wpeckham (Post 6492821)

It will be in the security and backport set of more conservative distributions shortly.

For Debian, only sid/unstable and trixie/testing were affected, supported releases were not affected:

Quote:

Originally Posted by https://security-tracker.debian.org/tracker/CVE-2024-3094

[bookworm] - xz-utils <not-affected> (Vulnerable code not present)
[bullseye] - xz-utils <not-affected> (Vulnerable code not present)
[buster] - xz-utils <not-affected> (Vulnerable code not present)

Not sure about others, but the above Debian page also has links to the issues for Red Hat, Ubuntu, Gentoo, SUSE.

I have been wondering why my debian-spawn raspberry pi had gone so loco, could this backdoor be the reason?

Looks like Debian reverted to an older version for now.

https://bugs.debian.org/cgi-bin/bugr...gi?bug=1068024

openSUSE response for Tumbleweed:

"For some regions, there is a long weekend ahead – so expect no / few
snapshots until early next week. For snapshot 0328, Ring0 has been
completely bootstrapped (as the attack vectors for xz were not fully
known, we went the safest route) and for 0329 all of Tumbleweed rebuilt
against that new base; Ezpect that snapshot to appear ‘large’ (even
though many packages will not be different). "
-
I am not an insider, but...

Bootstrapping usually means to build everything from source. It can also mean to start "clean" or from "nothing". Clean and nothing would depend on the context.

Ring 0 is, I assume, is a set of critical/basic software required to build the distribution and possibly installation media. I am aware of this list:
https://build.opensuse.org/project/s...gs:0-Bootstrap
-
We also took advantage of this rebuild to remove all the Python3.9 modules. So don't be surprised by upgrades of thousands of packages, just upgrade and very importantly, reboot your system.
-
*only* x86_64 was affected.
-
Best WIshes

The original author of XZ Utils (Lasse Collin, Larhzu) has posted an initial statement - there's not many details yet because they're still investigating. At time of writing it says:

Quote:

Originally Posted by https://tukaani.org/xz-backdoor/

XZ Utils backdoor

This page will get updated as I learn more about the incident.

The Git repositories of XZ projects are on git.tukaani.org.

The email address xz at tukaani dot org forwards to me only. This change was made on 2024-03-30.

xz.tukaani.org DNS name (CNAME) has been removed. XZ Utils currently doesn't have a home page. A few links on tukaani.org are still broken but many were fixed on 2024-04-04.

To media and reporters

I won't reply for now because first I need to understand the situation thoroughly enough. It's enough to reload this page once per 48 hours to check if this message has changed.

Email

I have gotten a lot of email. Thanks for the positive comments. Unfortunately I don't have time to reply to most of them.

Facts

CVE-2024-3094
XZ Utils 5.6.0 and 5.6.1 release tarballs contain a backdoor. These tarballs were created and signed by Jia Tan.
Tarballs created by Jia Tan were signed by him. Any tarballs signed by me were created by me.
GitHub accounts of both me (Larhzu) and Jia Tan were suspended. Mine was reinstated on 2024-04-02.
xz.tukaani.org (DNS CNAME) was hosted on GitHub pages and thus is down too. It might be moved to back to the main tukaani.org domain in the near future.
Only I have had access to the main tukaani.org website, git.tukaani.org repositories, and related files. Jia Tan only had access to things hosted on GitHub, including xz.tukaani.org subdomain (and only that subdomain).

Plans

I plan to write an article how the backdoor got into the releases and what can be learned from this. I'm still studying the details.

xz.git needs to be gotten to a state where I'm happy to say I fully approve its contents. It's possible that the recent commits in master will be rebased to purge the malicious files from the Git history so that people don't download them in any form when they clone the repo. The old repository could still be preserved in a separate read-only repository for history: the contents of its last commit could equal some commit in the new repository.

These will unfortunately but obviously take several days.

A clean XZ Utils release version could jump to 5.8.0. Some wish that it clearly separates the clean one from the bad 5.6.x.

Links

Last updated 2024-04-04 22:53:08 +0300

For the paranoid, https://tukaani.org/xz-backdoor/ currently contains no JavaScript nor remote resources - only a single image and a single stylesheet, and the page loads fine with both those disabled.

Interesting to note that if you pulled the GIT source instead of the tar file you would never see or use the infected code. Some distributions were immune because of that alone
.
Interesting that if your distribution does not use the SYSTEMD init 0 that you are immune.

Interesting that the ONLY reason the library was ever included in SSHD was as a kludge to support SYSTEMD!

Interesting that desktop/client installations that do not run SSHD were immune.

The entire purpose of the injection appears to have been to provide a back door on servers running SYSTEMD using SSHD for secure remote access.

I am now having a longer and more thoughtful look at distributions that have never used SYSTEMD!

Although only a server should need to have something like sshd active, over the years I have seen many times when linux newbs have been advised to setup sshd, "just because their system will be more secure".

When I was installing slackware lately, I saw that it would enable sshd as a system service by default, except I cleared the asterix for that. How many other distros might be enabling sshd by default?

When you are looking for distros which do not use systemd, you should not count Slackware as one of them. Although there has been the discussion of how Slackware has not yet gone over to systemd - I just checked on my system, In fact systemd is already cooked into Slackware 15.0 - and systemd is running dbus, elogind, blueman, and emacs. For a few minutes I tried to disable it, or to rename it, to find some way for it not to load. No good, it is cooked into things so well I can not get rid of it.

It appears slackware may be less than candid about it's involvement with systemd. So I can not trust it anymore.

Quote:

Originally Posted by wpeckham (Post 6494427)

Quote:

Originally Posted by mw.decavia (Post 6494453)

It appears slackware may be less than candid about it's involvement with systemd. So I can not trust it anymore.

Don't see what the hurdle is.
If you do not need it for now, disable it.
'/etc/rc.d/rc.sshd stop' followed with 'chmod -x /etc/rc.d/rc.sshd'

If you do need it and wants to remain somewhat safe on the net, then stay away from systemd distros.

What a systemd free install returns in my Terminal

Code:

$ xz -V

xz (XZ Utils) 5.4.1

liblzma 5.4.1

harry@antiX-23.1:~

$ ldd /usr/sbin/sshd | grep 'lzma|systemd'

harry@antiX-23.1:~

$

If any return output on ldd command is what to look out for. I run stable and backports instead of testing and sid repos also.
Not nervous here.