Mastodawn

Ariadne Conill 🐰

as I explain in my blog, the real problem is libraries which are large amalgamations of unrelated routines, such as libsystemd in the case of CVE-2024-3094.

a good solution is to split up these giant libraries into smaller ones, thus allowing for the dependency graphs of programs to remain leaner.

there is nothing about sd_notify() which requires LZMA compression. nothing. it is a function which writes a supplied string to a UNIX socket, the path of which is provided on an environmental variable.

Amir Livne Bar-on Apr 2, 2024

@ariadne does tree shaking (the type that's common in statically linked languages) solve this completely? or is it not enough?

James Henstridge Apr 2, 2024

@Pashhur @ariadne tree shaking generally preserves side effects from importing modules/linking libraries.

You could argue that ifunc resolvers shouldn't call until the first time the function is called, but there's a bunch of other ways a library can have code run at program initialisation time.

David JONES Apr 2, 2024

@ariadne "Let Unix be Unix" ... Is the catchphrase I came up with yesterday. I have some thoughts around it, but they have yet to coalesce into an article. Needless to say, part of it was that systemd does not follow this philosophy.

Ariadne Conill 🐰

@drj to be absolutely clear, while i point to libsystemd as being a key part of the exploitation chain for this xz backdoor, i am really uninterested in hearing random pet arguments on systemd not being UNIX enough. the horse is beaten, it is not just dying, it is entirely dead at this point.

David JONES Apr 2, 2024

asu Apr 2, 2024

@ariadne @drj not just that but the irony is that half of how the backdoor was so easy to hide in the build scripts is because of the tools purists would love to consider peak unix philosophy

David JONES Apr 2, 2024

@asu I think you might have confused GNU with Unix, because i don't consider m4 and autotools as part of "Let Unix be Unix". I don't disagree with you on the irony though; i'm just not sure which way it goes. 😂

Who whole thing _looks_ like it was "fortuitous" (that xz used m4 for example, or that systemd injects lzma into sshd), but actually it's the result of what was presumably quite a careful hunt for a set of tools with just the right injectable properties.

Ziggy the Hamster ☎️ 4ZTH Apr 2, 2024

@drj @ariadne tell me you know nothing about how systemd is architected without telling me you know nothing about how systemd is architected

(Hint: it’s a whole bunch of “Unix philosophy” binaries, united in their mission.)

Ziggy the Hamster ☎️ 4ZTH Apr 2, 2024

@drj @ariadne it’s perfectly valid to criticize systemd because it’s opinionated and you don’t like its opinions (maybe you’re a vintage configuration file format maximalist)

But “it’s not Unix philosophy” isn’t valid

David JONES Apr 2, 2024

@ZiggyTheHamster a) a follow up post wasn't necessary; b) it's clear that phrases like "Let Unix be Unix" and "Follows Unix Philosophy" are just cover for "i don't like it".

I almost didn't mention systemd in my reply (as it's a fairly ancillary part of both the xz attack and "Let Unix be Unix"). So there's a lesson learned.

Ziggy the Hamster ☎️ 4ZTH Apr 2, 2024

@drj except your reply is entirely dependent on the incorrect assertion that systemd doesn’t follow the Unix philosophy and not mentioning systemd makes your entire reply not make any sense

David JONES Apr 2, 2024

@ZiggyTheHamster ok keith

Firstyear Apr 2, 2024

@ariadne systemd never documented the sd notify unix socket, forcing people to intitally exec() to a binary and later linking to their own library.

Ariadne Conill 🐰

@firstyear riveting tale, if only it were actually true:

https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html

> These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable.

sd_notify

Ariadne Conill 🐰

@firstyear this string is present since the beginning of sd_notify()'s manpage in 2010: https://github.com/systemd/systemd/commit/f9378423b9758861850748aeb49ae0d3300e56e6

man: document sd-daemon.[ch] · systemd/systemd@f937842

The systemd System and Service Manager . Contribute to systemd/systemd development by creating an account on GitHub.

GitHub

Firstyear Apr 2, 2024

@ariadne Yep youre right and I missed that. Ive read that documentation many times and never saw that line, and many others have missed it also. To improve its visibility maybe it needs it's own section rather than being a single line in the middle of the NOTES section? It shouldnt be an afterthought.

Laurent Bercot Apr 2, 2024

@ariadne You're not that different from anyone else pointing at their pet explanation. You are right, partially. So are most others.

Library bloat is one of the causes of the attack, yes. So are most things people mention. That's what's fascinating about this attack: it worked because of a perfect combination of factors weakening the security of FOSS.

Individually, improving one of these factors will make this precise attack impossible. But the problem is bigger than one single thing, though library bloat is a big part of it.

Edit: I read your blog entry, and fully agree with it. I still think there are more factors involved, e.g. build system complexity, to name only one.

daniel:// stenberg://Apr 2, 2024

@ska @ariadne I disagree. This attack was not about bloat. It is about the way we develop open source. Components developed by maintainers and the maintainers are given powers to do stuff. A malicious maintainer is very hard to find and prevent.

Laurent Bercot Apr 2, 2024

@bagder @ariadne And you are also right. Trust is built in the FOSS development model. So a part of the puzzle is: how can we keep that development model, which has made FOSS successful, while screening for malicious maintainers more efficiently?

Part of the answer is more peer review, which means more people involved, which means, as always, more funding. But it's not the whole answer either.

daniel:// stenberg://Apr 2, 2024

@ska @ariadne there is no easy fix for this, but I believe the focus need to be in detecting anomalies after the fact rather than thinking we can get rid of malicious maintainers

Laurent Bercot Apr 2, 2024

@bagder @ariadne We obviously can never get rid of malicious maintainers, though the ratio is extremely low and the fact that this doesn't happen more often is to me a measure of *success* of the FOSS model. Even if there are two or three more similar attacks in the wild that have not been detected, that's really small compared to the amount of good faith maintainers.

When I say "screening for malicious maintainers", I really mean ensuring the correctness of contributions that make it in.

Detecting anomalies can be a part of the solution, but there's so much work to be done towards prevention as well. And when I think "anomaly detection", I think "reproducible builds", which are also a prevention tool.

(Edit: added a paragraph to clarify my meaning in the previous post.)

daniel:// stenberg://Apr 2, 2024

@ska @ariadne yes, it will help as in we need to tighten the screws all over the ship - but the xz attacker was only a tiny commit away from reproducible builds

Laurent Bercot Apr 2, 2024

@bagder @ariadne We're in agreement here. I'm not touting reproducible builds as the solution, just mentioning them since you were talking about anomaly detection.

Tightening the screws all over the ship is a perfect metaphor for what needs to be done - the attack exposed several weaknesses in the FOSS ecosystem and they all need to be addressed. I don't think it can be plausibly done without fueling more resources into the community, though.

daniel:// stenberg://Apr 2, 2024

@ska @ariadne "more resources" is most likely one of the screws, yes.