Kevin BeaumontMar 31, 2024

I don’t agree with all the doom saying about XZ incident.

You just know orgs are going to return after Easter and panic about it unnecessarily (they’re likely still on Redhat 6). It doesn’t impact them as it was caught super early.

Regarding the narrative that there’s nothing that can be done about these type of attacks - I also don’t agree. There’s already a change in the pipeline to systemd which would have prevented it.

The thing needs rational, calm reaction and response.

Show threadKevin BeaumontMar 31, 2024

Before anybody points it out, I know I am in the wrong industry if I want rational calm response - LinkedIn in still full of people saying the boat got ‘cyber attacked’, and governments are busy trying to solve supply chain risks by banning HUAWEI.

The industry is basically powered by people running into a crowded theatre and shouting CYBER. Then when people point out there’s no cyber, they’re like ‘yes.. but there COULD be cyber’. Thanks, very helpful.

Show threadKevin Beaumont

For those asking what systemd change, easy write up: https://github.com/systemd/systemd/issues/32028

It was in train before the XZ issue was discovered, which may be why the threat actor sped up, started making mistakes and started begging distros to upgrade XZ - as what looks to be years of planning was about to be flushed down the pan.

Reduce dependencies of libsystemd · Issue #32028 · systemd/systemd

Component systemd Is your feature request related to a problem? Please describe The recent sshd/xz backdoor fiasco (CVE-2024-3094) has shown that the extra dependencies introduced by libsystemd may...

GitHub
Mar 31, 2024 at 10:49amWeb
Show threadCassandrichMar 31, 2024
@GossiTheDog Are they deprecating the sd notify library call so that all the programs gratuitously linking libsystemd for socket notification will instead have to read the spec and write the 5 lines of code needed to do it by the spec rather than by a library function? This would help so much to undo the damage systemd did to dependency creep.
Show threadSimon RichterMar 31, 2024
@dalias @GossiTheDog yes, basically the boilerplate code you need for systemd integration is about the same as you need for normal daemons and running from inetd, so there is no point using a library.
Show threadCassandrichMar 31, 2024
@GossiTheDog Uhg no, apparently that would "make future evolution of these protocols more difficult". They're saying the quiet part out loud.
Show threadLisPiApr 1, 2024
@dalias @GossiTheDog I can't seem to even *find* the socket documentation you mention when I look it up.

Basically every result that comes up is a redundant result for systemd-notify or the sd_notify library call.
Show threadLisPiApr 1, 2024
@GossiTheDog @dalias Okay, so for *some reason* the socket is only documented properly in the manpage for the library call to be removed. (But why?)

Hopefully that'll be moved somewhere more sensible?
Show threadshanaMar 31, 2024
@GossiTheDog That change will never happen, though - systemd has been a spaghetti ball of interconnected code with no architectural boundaries since the very beginning, and they have *never* even accepted that doing it like that is a fundamental design problem, let alone consider any changes that would make the ball a bit more modular and potentially splittable into components. They're going to hide some things behind dlopen and call it a day.
Show threadRandom Damage 🌻Mar 31, 2024

@GossiTheDog systemd is still fertile ground for finding vulnerabilities.

It's a core system component whose developers are determined to make more complex than it needs to be

Show threadzbrownMar 31, 2024

@RandomDamage @GossiTheDog systemd is a project with high visibility, defined maintenance/security processes, and a half decent bus factor.

Hard to see what one actually gains by splitting it into a dozen or so little repos like #xz

Show threadPär BjörklundMar 31, 2024

@GossiTheDog these proposed changes don't protect against a similar attack though. They do reduce the attack surface making it harder to pull off.

Just moving to dlopen depends a lot on the implementation and how easy it is to trigger the loading of a vulnerable library

Show threadMark RoszkoMar 31, 2024

@GossiTheDog The systemd change would have sealed off the ssh attacker vector. But liblzma is linked into plenty of other libraries. Just using rdepends even python,tor has a depend on it. So they could have still had value in alternate attack vectors, just not ssh which may have been more universal.

Heck libxml2 depends on liblzma5, so there are even more attack targets like postgres, ruby, php, etc

Kind of a waste to rush, but it may be why they added a plugin system for additional payloads.