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