Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 8 submissions in the queue.
Breaking News
posted by hubie on Saturday March 30 2024, @07:23AM   Printer-friendly

xz-utils are compromised and inject malicious code

= Debian:

https://lists.debian.org/debian-security-announce/2024/msg00057.html
https://security-tracker.debian.org/tracker/CVE-2024-3094

Debian Security Advisory DSA-5649-1
[SECURITY] [DSA 5649-1] xz-utils security update

Package : xz-utils
CVE ID : CVE-2024-3094

Andres Freund discovered that the upstream source tarballs for xz-utils,
the XZ-format compression utilities, are compromised and inject
malicious code, at build time, into the resulting liblzma5 library.

Right now no Debian stable versions are known to be affected.
Compromised packages were part of the Debian testing, unstable and
experimental distributions, with versions ranging from 5.5.1alpha-0.1
(uploaded on 2024-02-01), up to and including 5.6.1-1. The package has
been reverted to use the upstream 5.4.5 code, which we have versioned
5.6.1+really5.4.5-1.

Users running Debian testing and unstable are urged to update the
xz-utils packages.

For the detailed security status of xz-utils please refer to
its security tracker page at:
https://security-tracker.debian.org/tracker/xz-utils

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org

= Red Hat:

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

"What distributions are affected by this malicious code?

Current investigation indicates that the packages are only present in Fedora 41 and Fedora Rawhide within the Red Hat community ecosystem.

No versions of Red Hat Enterprise Linux (RHEL) are affected.

We have reports and evidence of the injections successfully building in xz 5.6.x versions built for Debian unstable (Sid). Other distributions may also be affected. Users of other distributions should consult with their distributors for guidance."

https://www.openwall.com/lists/oss-security/2024/03/29/4

= OpenWall: (With more details at openwall link above)

"After observing a few odd symptoms around liblzma (part of the xz package) on
Debian sid installations over the last weeks (logins with ssh taking a lot of
CPU, valgrind errors) I figured out the answer:

The upstream xz repository and the xz tarballs have been backdoored.

At first I thought this was a compromise of debian's package, but it turns out
to be upstream."


Original Submission

Related Stories

A Review of the OpenSSH Backdoors in Recent Decades 7 comments

Ben Hawkes over at Isoceles has a review of the two OpenSSH Backdoor attempts. One, the XZ backdoor, was attempted this year in early 2024. The other, in 2002, was a matter of attempting to trojanize some distribution files.

Inserting an exploitable bug (a "bugdoor"), one that's subtle enough that developers might not even notice during code review, is probably the winning move. However, it's interesting to note that in both 2002 and 2024 we got a backdoor rather than a bugdoor. That's probably because exploits are hard, and server-side exploits are really hard. Given how much work it is to be in a position to change the source code in the first place, it's not entirely surprising that attackers want to go with a reliable option. The counter-argument is that we may just never get to see any bugdoors because they never get caught (or if they do, they don't get flagged as subterfuge), so we're biased towards the events that we can actually detect.

There are other similarities. Both the 2002 and 2024 events targeted the build system, for example. This also makes sense, because build systems are a perfect mix of inscrutability and expressiveness. There's really no constraints on what you can do with most build systems. They have to be like this in order to make everything work everywhere that it's supposed to. Making something compile on Linux, MacOS, and Windows simultaneously is no easy feat. Add in support for multiple architectures and legacy versions, and well... you see where I'm going with this. The guiding design principle for build systems has been "just make it work", and so they end up being a complicated mess of directives, rules, variables, and command invocations. As long as they're working correctly, I suspect very few people are paying close attention to the contents of their build scripts, and that includes the developers/maintainers themselves. It's the ideal place to insert the first hook for a backdoor, hiding in plain sight.

Most bugs have not been added intentionally.

Previously:
(2024) The Mystery of 'Jia Tan,' the XZ Backdoor Mastermind
(2024) xz: Upstream Repository and the xz Tarballs Have Been Backdoored


Original Submission

This discussion was created by hubie (1068) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 5, Interesting) by AlwaysNever on Saturday March 30 2024, @07:45AM (15 children)

    by AlwaysNever (5817) on Saturday March 30 2024, @07:45AM (#1350982)

    ...to compromise sshd via the systemd dependency on the compromised xy library.

    Thanks, systemd.

    • (Score: 3, Insightful) by janrinok on Saturday March 30 2024, @08:03AM (14 children)

      by janrinok (52) Subscriber Badge on Saturday March 30 2024, @08:03AM (#1350983) Journal

      Right now no Debian stable versions are known to be affected.

      It wouldn't matter which OS you were using, if you get a compromised package into your system then anything that depends on that package will be compromised too. I understand your systemd hate, but that isn't the issue here. The problem is that there are no checks being made by a second person on code commits upstream.

      --
      I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
      • (Score: 5, Insightful) by Unixnut on Saturday March 30 2024, @08:27AM (12 children)

        by Unixnut (5779) on Saturday March 30 2024, @08:27AM (#1350984)

        I think his point was that sshd would not have been vulnerable had it not needed to interface with systemd for notifications. That was the requirement that pulled in the xz library which resulted in this compromise.

        I generally agree with the sentiment that core systems for things like remote access (i.e. ssh) should have the smallest attack surface possible and therefore should avoid any dependencies that are not critical to its functioning. Integrating systemd notifications is one of those "non critical" functions, especially as there are alternative ways to notify systemd that doesn't involve library integration.

        Thankfully I only run BSD and Devuan stable, and have checked that my versions are not vulnerable, however for others this could be quite a headache to deal with.

        • (Score: 3, Insightful) by janrinok on Saturday March 30 2024, @09:55AM (11 children)

          by janrinok (52) Subscriber Badge on Saturday March 30 2024, @09:55AM (#1350989) Journal

          I understood that.

          For me, the fact that nobody is checking commits into a repo is a much more serious problem. I have several programs that use xz-utils (current version 5.2!) so which one of them should shoulder the blame is less important to me. If you read other links by searching on Goog, then you will find a lot of discussion about 'how' this could have happened.

          --
          I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
          • (Score: 5, Interesting) by canopic jug on Saturday March 30 2024, @10:50AM (9 children)

            by canopic jug (3949) Subscriber Badge on Saturday March 30 2024, @10:50AM (#1350993) Journal

            Here is a writeup at somewhat dodgy site, Substack, but forwarded via the OpenBSD Misc mailing list. OpenBSD, the developers of OpenSSH, have a stake in this:

            Here’s what we know so far: some time ago, an unknown party evidently noticed that liblzma (aka xz) — a relatively obscure open-source compression library — was a dependency of OpenSSH, a security-critical remote administration tool used to manage millions of servers around the world. This dependency existed not because of a deliberate design decision by the developers of OpenSSH, but because of a kludge added by some Linux distributions to integrate the tool with the operating system’s newfangled orchestration service, systemd.

            Technologist vs spy: the xz backdoor debate [substack.com]

            At some point some Linux distros make their edition of OpenSSH dependent on systemd. Then, seeing that, apparently someone tracked down a systemd dependency where there was a single, tired, and ailing maintainer. Then a fake persona was set up followed by a slew of sock puppet accounts pushing the original, lone, tired, and ailing maintainer to hand over the reins. Once in charge, the fake account did maintenance for a while before eventually using the increased access to ease a well hidden backdoor inside one of the build scripts.

            Systems which do not use systemd, and instead follow the KISS principle, are obviously not affected.

            With the rebuilding of the Soylent News servers in the future, I hope that an OS or distro without SystemD is deployed. On the server, there's no excuse ever for systemd.

            --
            Money is not free speech. Elections should not be auctions.
            • (Score: 1, Disagree) by gnuman on Saturday March 30 2024, @02:22PM (4 children)

              by gnuman (5013) on Saturday March 30 2024, @02:22PM (#1351007)

              With the rebuilding of the Soylent News servers in the future, I hope that an OS or distro without SystemD is deployed. On the server, there's no excuse ever for systemd.

              Wait, is this the argument along the lines of "but what was she wearing"? Because systemd had nothing to do with this attack vector. If maintainers don't want, they can turn off systemd integration. Easy.

              https://docs.kernel.org/staging/xz.html [kernel.org]

              The so called "poorly maintained library" had a kernel module to accelerate things. Similarly, zlib has dedicated hardware acceleration on specific architectures.

              So, how about we blame the malicious actor that planned adding these things months, if not years, ahead of time via fake "example of corrupted archive" in test data? This exploit was not enabled in the git repo. It was enabled in the release tarball only. The git repo that actually had reviewed code didn't have this exploit activated.

              • (Score: 5, Insightful) by canopic jug on Saturday March 30 2024, @02:42PM (3 children)

                by canopic jug (3949) Subscriber Badge on Saturday March 30 2024, @02:42PM (#1351011) Journal

                The vector for the OpenSSH compromise was via a library required by systemd. On systems without systemd, and without systemd being tied into OpenSSH, there is no problem for OpenSSH. See the linked article in my post above.

                Furthermore, turning off systemd integration is very hard. It's not a trivial task, such as being a matter of a configuration setting. Observe the enormous effort required to sanitize packages from Debian to create systemd-free Devuan. It's not easy work in the least and, on top of that, there is an increasing volume that work to do as systemd metastasizes further through out Debian varied packages.

                At the end of the day it comes down to xz being compromised with some really obfuscated code which activates only in OpenSSH. Having a bad copy of xz won't in and of itself let your system get breached. However, having xz compromise an Internet-facing OpenSSH daemon via systemd will. The offending xz code is still being analyzed so this is really a developing story and could have gone under the Breaking News category instead.

                --
                Money is not free speech. Elections should not be auctions.
                • (Score: 4, Interesting) by sjames on Saturday March 30 2024, @07:08PM (2 children)

                  by sjames (2882) on Saturday March 30 2024, @07:08PM (#1351035) Journal

                  It's complicated enough that Devuan needs to have a stub library just to satisfy dependencied buried deep into build scripts in order to be rid of it.

                  So "just configure it out" is a lie.

                  • (Score: 3, Interesting) by gnuman on Saturday March 30 2024, @10:32PM (1 child)

                    by gnuman (5013) on Saturday March 30 2024, @10:32PM (#1351057)

                    So "just configure it out" is a lie.

                    In case of OpenSSH, it's literally a config option, considering that it runs on BSD systems that don't have the "evil systemd". As for the rest, you may need to add a config option along with patch in case the current code don't care about your usecase -- that's how open source works, no?

                    Anyway, the fun part is that most of the 3rd party dependencies are struggling to get maintainers. Just look at state of OpenSSL prior to Heart Bleed and that is far more core library than anything SSH. You'll find more people wanting to rewrite stuff in Rust than to maintain a 20 year old code base that has accumulated dozens of corner cases and optimizations. Add to that the lack of motivation from the current generation about free software in general -- everyone takes it for granted that someone else will do it. Who cares now that you use GPL vs. BSD? Younger crowd doesn't.

                    As for Systemd, it is simply a scapegoat here. I hope it's quite obvious. And if you don't want to use it -- hey, you have containers for everything anyway and no systemd or init there ;)

                    • (Score: 3, Interesting) by acid andy on Sunday March 31 2024, @12:24AM

                      by acid andy (1683) on Sunday March 31 2024, @12:24AM (#1351067) Homepage Journal

                      Add to that the lack of motivation from the current generation about free software in general -- everyone takes it for granted that someone else will do it. Who cares now that you use GPL vs. BSD? Younger crowd doesn't.

                      Now that's depressing. If that's true it probably deserves an article or journal entry all to itself. I guess if you grow up today with walled gardens, zero expectation of privacy, and no spare time or energy because it all goes into trying to pay for the essentials, FOSS might not mean so much to you, huh?

                      --
                      Welcome to Edgeways. Words should apply in advance as spaces are highly limite—
            • (Score: 3, Interesting) by Unixnut on Saturday March 30 2024, @07:50PM (3 children)

              by Unixnut (5779) on Saturday March 30 2024, @07:50PM (#1351040)

              I agree with all you said, however this bit caught my eye:

              On the server, there's no excuse ever for systemd.

              Why just servers?

              I've been running Devuan on the desktop since the Veteran Unix Admins forked it from Debian. In all these years I can't think of a single time I said "oh I really wish I was running systemd right now, it would make what I am trying to do so much easier and better". Not once in all that time. I did thank my lucky stars on a few occasions for not running systemd (this backdoor being yet another one of those moments) though.

              While I am sure a lot of this seamless experience is thanks to the tireless work of the Devuan volunteers, I would like to know if anyone has actually hit some roadblocks on Linux when not running systemd? I've yet to hit one and I use Linux heavily on the desktop.

              • (Score: 5, Insightful) by turgid on Saturday March 30 2024, @08:15PM (2 children)

                by turgid (4318) Subscriber Badge on Saturday March 30 2024, @08:15PM (#1351045) Journal

                Slackware all the way here, since 1995.

                • (Score: 2) by Unixnut on Saturday March 30 2024, @08:51PM (1 child)

                  by Unixnut (5779) on Saturday March 30 2024, @08:51PM (#1351047)

                  Hail Bob! Respect for using Slackware.

                  Back in the mists of my mind I remember considering moving to Slackware after my first foray in Linux with Red Hat (and RPM dependency hell). I guess the lack of an installer and the fact there was no dependency resolution put me off. I already had enough with binary package dependencies, last thing I needed was the same experience with source package compiling. I ended up using SuSe until they were bought out, then moved to Debian (with a diversion into Gentoo) and now Devuan.

                  How is Slackware nowadays? Still as raw as it was decades ago?

                  • (Score: 3, Interesting) by turgid on Sunday March 31 2024, @10:12AM

                    by turgid (4318) Subscriber Badge on Sunday March 31 2024, @10:12AM (#1351090) Journal

                    To install it, you need to know how to partition a disk, but that's about as technical as it gets. It's all menu driven. Hard disks are so big nowadays, packages are mostly irrelevant. You just install the whole distro. Having said that, You can get third party packages from slackbuilds and or compile them yourself, or even just compile directly from source, which is what I mainly do.

                    It comes with KDE but I don't use it. I use plain old Window Maker. It's a great compromise between a certain level of minimalism and user-friendliness.

          • (Score: 2) by fab23 on Saturday March 30 2024, @08:05PM

            by fab23 (6605) Subscriber Badge on Saturday March 30 2024, @08:05PM (#1351042) Homepage Journal
            As far as I understand in the case of xz, it had a part in code (git repository), but some more files needed for the backdoor to work have been added only into the distribution tarballs.
            The xz project was founded by Lasse Collin. Based on comments mention in the discussion on the oss-security mailing list he was/is also struggling with other things in life and so he had assigned another committer into the project. With his statement regarding this incident [tukaani.org] he brings some light into this. It is also archived in this posting [openwall.com] on the oss-security mailing list.
      • (Score: 4, Informative) by canopic jug on Saturday March 30 2024, @06:57PM

        by canopic jug (3949) Subscriber Badge on Saturday March 30 2024, @06:57PM (#1351033) Journal

        Evan Boehs is updating a timeline about events related to the Xz Backdoor [boehs.org] as more information becomes available. Among other things, he is tracking commits by the principle people involved.

        --
        Money is not free speech. Elections should not be auctions.
  • (Score: 3, Interesting) by bzipitidoo on Saturday March 30 2024, @08:53AM (6 children)

    by bzipitidoo (4388) on Saturday March 30 2024, @08:53AM (#1350985) Journal

    I suppose better security for Linux is overdue. For native Linux virus scanners, I know of only ClamAV. In general Linux security depends too much on system and network administrators checking things manually and keeping a sharp eye open for anything anomalous.

    How do you detect this? By noticing that /var/log/messages has recorded a lot of remote logins via ssh? Even if intruders don't cover their tracks by erasing such evidence from the logs, that method still involves finding out that your system is compromised well after the fact. So, by hearing this news that xz might be compromised? Then, if you try "xz --version" of course you may be running the compromised code. File tells you some things about a binary, but not the version. To find out which version I had without running it, I settled on a hexdump of the xz binary, and a search through that for "5.4" and "5.6". And I found the version number almost right away. I have 5.4.6. With that assurance that I didn't have the compromised version, I verified that xz self-reported the same version number.

    • (Score: 2) by PiMuNu on Saturday March 30 2024, @08:56AM

      by PiMuNu (3823) on Saturday March 30 2024, @08:56AM (#1350987)

      For apt users, I believe 'apt-show-versions' will work, unless the apt setup has been compromised in some improbable way.

    • (Score: 2) by DrkShadow on Saturday March 30 2024, @11:06AM

      by DrkShadow (1404) on Saturday March 30 2024, @11:06AM (#1350995)

      how to check xz without running it?

      This is such a dumb question. I'm going to have to edit my definition of "dumb question," because this is one.

      You either already are running it, it's *already loaded* into your SSHD, or you're not vulnerable. Or, MAAAYBE, you have installed openssh server but you don't have it set up to RUN. (Such people are not asking this question.)

      So check it or forever wonder.

    • (Score: 2) by Rich on Saturday March 30 2024, @11:57AM (1 child)

      by Rich (945) on Saturday March 30 2024, @11:57AM (#1350999) Journal

      What can you do against such upstream attacks with a "virus scanner"? These look legit until they are discovered and then the notification path through your distro upgrade is one stop shorter than through any anti-malware solution and then through your distro upgrade.

      A scanner can point out something that is supposed to be not there. It is outclassed by a sealed base system (*), which makes sure that everythis is as it is supposed to be. Beyond that it's trust in the upstream suppliers. Did anyone grill the people (or "people") responsible for the Debian PRNG and Apple "goto fail" issues about what went on? Will anyone investigate what was behind "Jia Lin"?

      Sidenote: It was bizarre that this was discovered by some guy at Microsoft, and I'd assume that he was not part of any conspiracy, because the number of conspirators has to be kept small to keep the secret from leaking. If a great number of people were involved in such operations, someone would eventually become disgruntled and disclose and/or defect.

      (*) tough for me to write this, but asl long as you can unseal/seal yourself without penalty, it should be fine.

      • (Score: 2) by bzipitidoo on Saturday March 30 2024, @10:58PM

        by bzipitidoo (4388) on Saturday March 30 2024, @10:58PM (#1351060) Journal

        Well, there's SELinux. The whole idea of SELinux is to restrict everything with much finer grained privileges than the rather crude classic UNIX permission system of "rwx" with user segregation. Permission to access networking, graphics, system info, and so forth is not applied only to users, it is also applied to individual programs. In this case, there's no reason for xz or the lzma library to have access to networking. Wouldn't matter which user was running xz, SELinux would stop xz from accessing networking regardless.

        But SELinux is a huge pain to administer. You are constantly, constantly dogged by too many restrictions preventing legitimate code from doing what it was designed to do. No one wants to use SELinux if they don't absolutely have to. An example of how annoying SELinux can be is provided by ImageMagick of all things. Recently, ImageMagick has hobbled itself with this "policy" file that it reads to decide whether it is allowed to do as the user asked, and the default for working with PDFs has been "no". First order of business when I see an update to ImageMagick is edit that damned policy file to remove that restriction. Imagine that sort of thing on more than half the utilities in the system. That's what SELinux is. You'll be spending all your time removing restrictions that prevent you from doing damned near anything. Oh, you wanted to grep the log files? Sorry, grep isn't allowed to look at those files, sensitive data in there, you know. So you give grep that permission, and then, oh, you wanted to pipe grep's output to less? Sorry, less isn't allowed to use pipes or connect to grep or whatever. Want to load a log file into a text editor? More permission pains.

    • (Score: 1, Informative) by Anonymous Coward on Saturday March 30 2024, @12:53PM

      by Anonymous Coward on Saturday March 30 2024, @12:53PM (#1351003)

      The exploit is in liblzma rather than xz itself, and that code checks if the calling program is sshd - running xz itself is not dangerous, and there's little danger on a non-systemd or non-linux install. This exploit isn't going to effect anyone running a server, because they're almost certainly not running unstable releases.

    • (Score: 5, Insightful) by Mojibake Tengu on Saturday March 30 2024, @04:40PM

      by Mojibake Tengu (8598) on Saturday March 30 2024, @04:40PM (#1351022) Journal

      Any intrusion into system base component is unmanageable. It is essential to keep system base small, for sanity of code auditors. Existence of (statically linked) /sbin in Unix was part of that sanity effort, for decades.

      On the contrary, Linux corporates generate marketing pressure by system base design bloat. It's economic decision, though anti-engineering.
      Demolition of /sbin, introduction of systemd, removal of operator account, all courtesy of Linux distros corporations, was instrumental in overall decreasing robustness of Linux platforms.
      At first glance all that looks pure stupid, but there is a strict strategy behind that. It's a Microsoft/Apple model of business narcissistic first rule (of eight classical narcissist rules) undermine others in an attempt to gain power or feel superior.

      Perhaps they will need to learn the harder way one day.

      --
      Rust programming language offends both my Intelligence and my Spirit.
  • (Score: 5, Interesting) by PiMuNu on Saturday March 30 2024, @08:54AM (12 children)

    by PiMuNu (3823) on Saturday March 30 2024, @08:54AM (#1350986)

    The good news is that this was caught, within two months and before it hit stable (also in my distro). The bad news is that it was probably quite a novice bad person doing the hacking, given the sorts of errors that they produced. A more professional person would not make these sorts of errors. Would it be caught? (Or better question - what hasn't been caught?)

    • (Score: 4, Insightful) by pTamok on Saturday March 30 2024, @12:48PM (7 children)

      by pTamok (3042) on Saturday March 30 2024, @12:48PM (#1351002)

      Or better question - what hasn't been caught?

      You are on the nose with that question.

      Which is the reason that (security-related) 'stuff' should be a simple as possible, and audited to hell and back.

      It is stunning that there is no standardised secure hardware for running a password manager (and keeping other secrets). People use 'smart'phones, which are basically a set of security vulnerabilities in solid form. PCs are little better (but don't generally have a broadband processor).

      Almost no-one takes security seriously. And on that point, Prof. Ross Anderson died yesterday.

      https://en.wikipedia.org/wiki/Ross_J._Anderson [wikipedia.org]

      https://news.ycombinator.com/item?id=39864210 [ycombinator.com]

      A great loss to the security community.

      • (Score: 4, Informative) by canopic jug on Saturday March 30 2024, @12:56PM (3 children)

        by canopic jug (3949) Subscriber Badge on Saturday March 30 2024, @12:56PM (#1351004) Journal

        A more appropriate link covering the death of security specialist Ross Anderson at Cambridge would be the post RIP Ross Anderson [lightbluetouchpaper.org] at The Light Blue Touch Paper at the University of Cambridge, where he worked. It's not nice to steer traffic to the censorious, anti-FOSS orange sites. Of his works, the Security Engineering: A Guide to Building Dependable Distributed Systems [cam.ac.uk], 3rd Edition, is well worth looking at.

        --
        Money is not free speech. Elections should not be auctions.
        • (Score: 2) by turgid on Saturday March 30 2024, @03:59PM (1 child)

          by turgid (4318) Subscriber Badge on Saturday March 30 2024, @03:59PM (#1351017) Journal

          Is Hacker News anti-FOSS?

          • (Score: 4, Insightful) by Anonymous Coward on Saturday March 30 2024, @05:18PM

            by Anonymous Coward on Saturday March 30 2024, @05:18PM (#1351027)

            More pro-corporate and pro-monetization-of-everything than anti-FOSS. The "hacker" contingent doesn't speak anywhere near as loudly as the "tech-bro-with-an-IPO" and contingent.

        • (Score: 1, Insightful) by Anonymous Coward on Saturday March 30 2024, @09:20PM

          by Anonymous Coward on Saturday March 30 2024, @09:20PM (#1351050)

          Please define, anti-FOSS orange sites. I too pleed ignorance.

      • (Score: 2) by sjames on Saturday March 30 2024, @07:57PM (2 children)

        by sjames (2882) on Saturday March 30 2024, @07:57PM (#1351041) Journal

        Even a secured well audited password manager does no good if a piece of software gets hacked to not actually check with the password manager before letting the bad guy in.

        • (Score: 1) by pTamok on Saturday March 30 2024, @08:27PM (1 child)

          by pTamok (3042) on Saturday March 30 2024, @08:27PM (#1351046)

          This is true.

          But I was thinking of storing passwords/phrases/other secret and/or private stuff on entirely separate hardware, which doesn't have hardware security enclaves running software signed with keys controlled by the hardware suppliers. We need open (audited) hardware and open (audited) software in a convenient small (portable and accessible) form factor.

          I was privileged to see the beginnings of the development process of just such hardware/software by some security professionals a few years ago. The project foundered because there was insufficient demand: not enough people understand the need, or the necessary attributes of a solution that fulfil the need. Proper use tends to being inconvenient. So most people use 'smart'phones and 2FA and devices like yubikeys.

          The security and intelligence agencies (and to lesser extent, law enforcement) do not want secure hardware generally available, mainly because it helps terrorists and 'the opposition'/the enemy.

          • (Score: 2) by sjames on Tuesday April 02 2024, @05:42PM

            by sjames (2882) on Tuesday April 02 2024, @05:42PM (#1351379) Journal

            I've looked at a number of 'enhanced' security options. Practically all of them leave the server dependent on the butt (cloud) making an authentication decision.

    • (Score: 5, Interesting) by gnuman on Saturday March 30 2024, @02:26PM (3 children)

      by gnuman (5013) on Saturday March 30 2024, @02:26PM (#1351008)

      This wasn't a novice doing the haxing. This took some planning and effort and obfuscation. It was caught only because someone was investigating a performance regression. Think about it.

      The crux of the problem is that we are not even checking if the release tarball contains the sources from the git repo. In this case, it didn't.

      • (Score: 3, Insightful) by turgid on Saturday March 30 2024, @03:47PM

        by turgid (4318) Subscriber Badge on Saturday March 30 2024, @03:47PM (#1351016) Journal

        People are way too lax in general about software quality. It's drudge work, but it's important.

      • (Score: 3, Interesting) by canopic jug on Saturday March 30 2024, @04:36PM (1 child)

        by canopic jug (3949) Subscriber Badge on Saturday March 30 2024, @04:36PM (#1351021) Journal

        The crux of the problem is that we are not even checking if the release tarball contains the sources from the git repo. In this case, it didn't.

        xz sounded like a one-man show which is hard on everybody not the least on the maintainer himself. It's ok to put put projects on ice and deaccession packages. With only one maintainer, xz could have been removed. As a positive example in that regard, the OpenBSD project has no qualms about dropping services, components, and such from its base system on the occasions when there is not a developer available to act as steward. Even with a steward, the code is not modified in isolation. From what I understand, all modifications by developers have to be approved by two other developers able to audit the modification. Third party contributions go through one of the approve developers.

        At least at this early stage when so little is known about the injected code, it looks like following that model would have prevented the backdoor from entering the code base: In the one case, xz would have been retired due to lack of developer support. In the other case, two other developers would have reviewed the code changes and might have caught the sneaky trick before adding it to the official code base.

        However, all of that also depends on valuing and prioritizing simplicity, correctness, and clarity. Much of the reason for the ever increasing complexity of the Linux distros seem to be non-technical and political. Complexity steers control of project over to the investors which can afford top work past the complexity. Sadly as side effect of the complexity is reduced security. In contrast, simplicity not only enhances security (audibility, plus if it's not there it can't break) it first and foremost decentralizes control and governance. That rubs some groups, including the powers that be, the wrong way.

        --
        Money is not free speech. Elections should not be auctions.
        • (Score: 2, Insightful) by Anonymous Coward on Saturday March 30 2024, @07:44PM

          by Anonymous Coward on Saturday March 30 2024, @07:44PM (#1351039)

          Note that xz is the default compression format used by most (all?) packages on Debian and Ubuntu. The default has been changed before, but simply removing it would require some care to not break existing systems.

          ... but having a core dependency effectively unmaintained is a bad look for Debian and they should probably be taking a serious look at the policies that got them there.

  • (Score: 4, Interesting) by turgid on Saturday March 30 2024, @04:12PM (1 child)

    by turgid (4318) Subscriber Badge on Saturday March 30 2024, @04:12PM (#1351018) Journal

    This reminds me of something I stumbled upon a few years back "Xz format inadequate for long-term archiving [nongnu.org]." It's more to do with the general design of the container format, but it was never great to begin with. Once I read that I started to use lzma instead for new stuff.

    • (Score: 3, Insightful) by Unixnut on Saturday March 30 2024, @08:57PM

      by Unixnut (5779) on Saturday March 30 2024, @08:57PM (#1351049)

      Thanks, that was an interesting read. Coupled with the latest news and the discovery that the original maintainer is struggling to find the time to maintain xz properly is making me consider moving away from xz for my backup system. Would have to see how good its parallel (de)compression speed is though as well as compression ratio.

  • (Score: 5, Insightful) by Anonymous Coward on Saturday March 30 2024, @05:06PM

    by Anonymous Coward on Saturday March 30 2024, @05:06PM (#1351024)
    Sigh, systemd again. Remember the good old days when issues like root exploits were just because systemd was not programmed well? That is, systemd was at fault exclusively rather than being an enabling conduit for situations like this?

    This is the price that is paid by Lennart and RedHat betraying the original philosophy of doing one thing and doing it well. I understand there are positives introduced by systemd, that certain features exist and problems are solved such as guaranteeing the correct order of service launching and so on... But at the expense of making an exploit like this possible is a raw deal.

    Here on Gentoo with OpenRC I'd be immune anyway, but the gentoo package tree has already pushed a downgrade to 5.4.2 for xz-utils (because Gentoo allows users to build with systemd if desired, so those system owners would be relevant). As for Raspbian I saw an "upgrade" to this version: xz-utils (5.6.1+really5.4.5-1).

    Going back to Gentoo real quick, 5.6.1 is in the tree but it is masked:

    - app-arch/xz-utils-5.6.1::gentoo (masked by: package.mask)
    /usr/portage/profiles/package.mask:
    # Sam James (2024-03-28)
    # Newer releases were signed by a potentially compromised upstream maintainer.
    # There is no evidence that these releases contain malicious code, but masked
    # out of an abundance of caution. See bug #928134.

  • (Score: 3, Insightful) by KritonK on Sunday March 31 2024, @08:13AM

    by KritonK (465) on Sunday March 31 2024, @08:13AM (#1351088)

    Forget about Debian and other stable releases. They use older versions of xz, and they are unaffected. It is rolling releases, such as Arch or OpenSUSE Tumbleweed, which use the latest and (apparently not so) greatest versions of everything.

    Tumbleweed, e.g., had been already using xz 5.6.1, and had to jump through a few hoops, to downgrade. They repackaged version 5.4.6 as version "5.6.1.revertto5.4", so that it would present itself to the package manager as a newer version of 5.6.1. They also placed a copy of this package in the seldom-used updates repository, so that people, who erroneously run the package manager with the "update" instead of the "dist-upgrade" option, would also get the update. Finally, they scheduled a rebuild of EVERYTHING, which came out today as a massive update, because they couldn't be sure what might have been affected by the backdoor, with a strong recommendation to reboot after installing the update.

  • (Score: 3, Funny) by cykros on Sunday March 31 2024, @07:45PM

    by cykros (989) on Sunday March 31 2024, @07:45PM (#1351127)

    "Right now no Debian stable versions are known to be affected."

    I'm half surprised Debian stable "already" is using xz files to begin with, given its propensity for being only having slightly closer to a cutting edge than OpenBSD.

(1)