Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
"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.
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
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!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.