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.

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.

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
@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.
@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.
@GossiTheDog Uhg no, apparently that would "make future evolution of these protocols more difficult". They're saying the quiet part out loud.
@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.
@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?
@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.

@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

@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

@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

@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.

@GossiTheDog it was depressing watching some people on the XZ IRC the 36ish hours I was lurking.

You had a small group of people trying to get hold of Lasse Collin, and get an FAQ and write-up done. A few trying to analyse the vuln.

And then people just joining to wildly speculate and draw insane conclusions like claiming Jia Tan means Come Home or some shit like that.

And then also another handful that kept trying to impersonate Jia Tan.

@kura @campuscodi @GossiTheDog strong "*I* am Spartacus!" energy from that last group.

@womble @campuscodi @GossiTheDog they were just trying to be disruptive.

They'd join, /nick and then survive with the jiatan nick for 30 seconds and then get force changed.

These were all people super late to the party.

And it fed the morons in the wild speculation group as they'd find people who'd previously been known as jiatan and start a witch hunt.

Just a group of real special people.

@kura @GossiTheDog bash.org #4281 (site is defunct, though)

@kura @GossiTheDog Welcome to the internet. Not everyone has to be an adult, nor is there a requirement to be one even if you are. Lol.

I lurked in that irc channel, there were definitely even teenagers in there trying to make shit jokes.

What ya gonna do :shrug:

@GossiTheDog
It's such a simple, dumb problem to run out of power and such bad luck to hit a bridge and even more amazing the bridge suddenly, totally collapsed, so it must be cyber or aliens. Never bad luck

There's probabilities for all options, but without any facts to go, most likely is human incompetence and bad luck