[Solved] xz backdoor in debian stable?

[nooblinx]

I see this in debian 12:

$ xz -V
xz (XZ Utils) 5.4.1
liblzma 5.4.1


am I in danger?

[mm3100]

According to Debian security announcement no:
https://lists.debian.org/debian-securit ... 00057.html

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.

[Diesel330]

Is this pre-installed software?

[Uptorn]

Bookmark this for those times when the argument is made that freezing software versions is a security risk.

[steve_v]

Bookmark this for those times when the argument is made that freezing software versions is a security risk.

Nah, I think I'll file it under "Why gratuitously linking everything against systemd is a bad idea".

As per the KISS principle, security-critical packages like openssh (or, ya know, init) should have as few third-party dependencies and load as few libraries as possible. Debian (and several other distros) patching systemd-notify support into sshd, against the recommendations of the openssh project and seemingly without regard for the added attack surface is exceedingly dumb.

Couple of choice takes from openssh bugtracker discussions on this:
(2016)

I'm not wild about letting that particular camel's nose into the tent.

(2024)

License incompatibility and library bloatedness were the reasons. Given recent events we're never going to take a dependency on libsystemd, though we might implement the notification protocol ourselves if it isn't too much work.

[cds60601]

Bookmark this for those times when the argument is made that freezing software versions is a security risk.

Nah, I think I'll file it under "Why gratuitously linking everything against systemd is a bad idea".

As per the KISS principle, security-critical packages like openssh (or, ya know, init) should have as few third-party dependencies and load as few libraries as possible. Debian (and several other distros) patching systemd-notify support into sshd without regard for the added attack surface is exceedingly dumb.

I wouldn't be surprised (attention, conspiracy theory ahead) if this was intentional really aimed at systemd.

[steve_v]

Possibly. Then again, if one were looking for a way to attack openssh then looking through the list of libs it loads for any projects in search of a new maintainer wouldn't be a terribly silly place to start.

Aside, the usual deflection from our lord-and-saviour Lennart and his clergy has already begun.

[lindi]

As per the KISS principle, security-critical packages like openssh (or, ya know, init) should have as few third-party dependencies and load as few libraries as possible. Debian (and several other distros) patching systemd-notify support into sshd, against the recommendations of the openssh project and seemingly without regard for the added attack surface is exceedingly dumb.

How would you approach this while still retaining systemd support? By patching openssh to support the systemd-notify interface without using an external library?

[cds60601]

How would you approach this while still retaining systemd support? By patching openssh to support the systemd-notify interface without using an external library?

Maybe the question should be, why would openssh need systemd support? It never did prior to systemd

[lindi]

Maybe the question should be, why would openssh need systemd support? I never did prior to systemd

For reliable operation under systemd? You can find some info from "man systemd.service" on what "Type=notify" means:

Code: Select all

Behavior of notify is similar to exec; however, it is expected that the service sends a "READY=1" notification message via sd_notify(3) or an equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after this notification message has been sent. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is missing or set to none, it will be forcibly set to main.

[cds60601]

Maybe the question should be, why would openssh need systemd support? I never did prior to systemd

For reliable operation under systemd?

I don't know. I'm not a developer. I am just a simple user asking simple questions.
I don't profess to know the answers, but I can certainly ask what seems to be logical questions.

[steve_v]

How would you approach this while still retaining systemd support? By patching openssh to support the systemd-notify interface without using an external library?

I wouldn't, because I personally don't consider "retaining systemd support" worth the effort, and find the idea of patching daemons to support a specific service manager somewhat distasteful in general.
That said, implementing basic protocol support in sshd itself (as opposed to linking libsystemd0) is the approach favored by both openssh (if someone manages to convince them they want it) and systemd:

Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. In particular non-C environments really should do their own native impl and not botjer wrapping libsystemd just for this.

OTOH, the openssh guys certainly know their stuff far better than I, so in reality I'd just leave the damn thing alone. Systemd requiring explicit support from daemons is a systemd problem.

[Uptorn]

Nah, I think I'll file it under "Why gratuitously linking everything against systemd is a bad idea".

To clarify, I mean preserving it as an example against the assertion that "software is only secure when it is always the most recent up-to-date everything" a la the Arch Linux mentality. Constant churn is no indicator of security.

[steve_v]

I mean preserving it as an example against the assertion that "software is only secure when it is always the most recent up-to-date everything"

Of course. This was just too good a "dependency bloat bad" and "I told you so (WRT systemd-entangling everything)" opportunity to pass up.

[lindi]

Systemd requiring explicit support from daemons is a systemd problem.

If you check the man page you can see it is not required but it does have a number of advantages since then systemd can reliable know when the service is ready.

[steve_v]

a number of advantages since then systemd can reliable know when the service is ready.

We all spent 2+ decades without this particular advantage, and I for one am still not particularly motivated by it. If openssh can be convinced to let in at least some part of the camel (i.e. implement sd_notify in sshd), that's their choice, otherwise: Don't need, don't want. Also, if history is any guide the whole camel will quite likely try to follow...

In any case I really don't see how this ever justified a dependency on libsystemd, beyond "that's the quickest and easiest way to implement sd_notify"... A pretty poor attitude to take when it comes to openssh, which for many is arguably the most security sensitive code running on their systems.

Frankly this kind of gratuitous dependency for the sake of non-critical "because it's there" "advantages" is and always was one of my main problems with the move to systemd. As an init system and service supervisor it's fine, as a middleware uber-library that does everything and everything links against, it's a horrible idea.

[CwF]

...it always comes down to hacking humans.

[Aki]

Hello @nooblinx,
I suppose the discussion can be marked as "solved" by manually adding the text tag "[solved]" at the beginning of the subject of the first message (after other tags, if any), since there's never been a backdoor from the xz program in current Debian Stable.

[nooblinx]

Hello @nooblinx,
I suppose the discussion can be marked as "solved" by manually adding the text tag "[solved]" at the beginning of the subject of the first message (after other tags, if any), since there's never been a backdoor from the xz program in current Debian Stable.

done