A backdoor in xz

Posted Mar 30, 2024 9:57 UTC (Sat) by cesarb (subscriber, #6266)
In reply to: A backdoor in xz by DimeCadmium
Parent article: A backdoor in xz

Another solution is the watchdog: the service has to tell the service manager "I'm still running!" periodically, otherwise it's treated as failed. Then the main effect of the initial "I'm running!" is that the timeout before it is given by TimeoutStartSec, and the timeout after it is given by WatchdogSec, which can be shorter (allowing for services which are slow to start, like heavy Java-based servers).

A backdoor in xz

Posted Mar 31, 2024 1:33 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (3 responses)

Til it tells the service manager "I'm still running" but never calls accept again. Notify-by-socket is precisely equivalent to notify-by-fork in terms of reliability.

The solution you are looking for is *monitoring*.

A backdoor in xz

Posted Mar 31, 2024 1:45 UTC (Sun) by intelfx (subscriber, #130118) [Link] (2 responses)

> Notify-by-socket is precisely equivalent to notify-by-fork in terms of reliability.

It might be "equivalent" in an information-theoretical sense (everything that can be achieved with one, is also achievable with the other), but it's absolutely not equivalent in _practical reliability_.

Setting up a proper "notifying" double-fork (which, I remind you, means that the immediate child has to wait for the grandchild to initialize and only then exit, because in most cases the initialization must be completed in the grandchild) is tenfold more _complicated_ and _easier to get wrong_ than simply writing a line into a pre-existing socket that the supervisor has prepared for you.

Even more: all known cases of proper notifying double-fork implementatoin involve creating a temporary pipe or socket between the child and the grandchild, precisely for the reasons described above. As such, we are choosing between a notify-by-socket implemented _once_ and a notify-by-socket implemented _over and over again_ in each daemon. The choice must be obvious, unless you specifically have an irrational axe to grind against systemd.

A backdoor in xz

Posted Mar 31, 2024 6:22 UTC (Sun) by DimeCadmium (subscriber, #157243) [Link] (1 responses)

> As such, we are choosing between a notify-by-socket implemented _once_ and a notify-by-socket implemented _over and over again_ in each daemon. The choice must be obvious,

Indeed it must be, considering that we are discussing the result of everyone sharing a single implementation of it.

A backdoor in xz

Posted Mar 31, 2024 12:25 UTC (Sun) by bluca (subscriber, #118303) [Link]

No, most of us are discussing the result of a multi-year-long sophisticated social engineering attack that preyed on underfunded and overworked unpaid maintainers to inject a complex backdoor. Yes, a handful of people are missing the wood for the trees because they are unable or unwilling to run a simple command to check the attack surface gained by backdooring xz:

$ apt-cache rdepends liblzma5 | wc -l
354

If it hadn't been libsystemd in the middle of the dependency chain, it would have been something else. The exploit was primed and ready to add more backdoors for other arbitrary workflows, with pre-prepared and unused "test files" signatures that we'll now never know what would have attacked.