[aborsy]

A back door in the same library is not likely. It drew attention and many looked into it.

What could be done to prevent supply chain attacks more broadly?

[bdd8f1df777b]

> A back door in the same library is not likely.

But libsystemd is not linked to xz only. By removing it, sshd is free of many other potential risks.

[aborsy]

Correct, I misread.

Still the question remains: what technology could be implemented to mitigate this type of attack (beyond sshd)?

For example, Linux sandboxing is poor, and SeLinux is not usually enforced.

[vimax]

Disable calling functions in transitive dependencies, force them to be direct dependencies.

Why should sshd be allowed to call an xz function directly without xz being an immediate dependency.

I'm not sure what all that would entail with the ifunc stuff, but I remember encountering a glibc linking change moving from Red Hat 6 to RH7 that did something similar and broke the build process for some legacy code.

[hulitu]

> what technology could be implemented to mitigate this type of attack (beyond sshd)?

UNIX ? (do one thing and do it well).

When your program links with 20 libraries, i have i very hard time to believe that security is one of your goals.

[fsflover]

See: Qubes OS.

[metalspoon]

I pointed out this weakness the other day on the internet. I got attacked by open source software armies.

[ratg13]

Maybe it was because you weren't pointing out anything new?

There was a pull request to stop linking liblzma into libsystemd a month before the backdoor was found

https://github.com/systemd/systemd/pull/31550

This was likely one of many things that pushed the attackers to work faster, and forced them into making mistakes.

[metalspoon]

No. They couldn't get along with the idea that some open source software packages should also sometimes be cut away, just like all other packages.

They felt threatened by the idea that open source maintenance can ever go wrong and started attacking me. They argued closed source was worse.

That was not my point at all. I was not raising a weakness of open source. I was just pointing out that linking to libsystemd had that kind of problem.

[ranger_danger]

FOSS zealots are not always security experts.

[flohofwoe]

Please don't throw despicable systemd zealots and honorable open source zealots into the same bucket ;)

[baobun]

Please don't bring group-identity politics here.

[ikekkdcjkfke]

Plot twist: systemd zealots were all sockpuppets

[trust_bt_verify]

Thanks for sharing.

[wrayjustin]

One way to reduce supply chain risks would be to reduce the supply chain. Less dependencies results in less risk.

For example, dropping the libsystemd dependency.

[dmitrygr]

> What could be done to prevent supply chain attacks more broadly?

The UNIX philosophy was right all along - each tool does one simple thing.

[growse]

I can't tell if this is sarcasm or not.

Most things we want to do are necessarily complex, so dogmatically adhering to "one simple thing" necessarily drives you towards a towering heap of composed dependencies.

If you want to get rid of the supply chain, you want everything specifically to be non-composable, so that everything has to be reinvented from scratch for that specific solution.

[dmitrygr]

Try that supply chain attack on dropbear running as ssh server on devuan. Simple utility on a simple system made of simple utilities

[3v1n0]

Indeed it's not.

But this implies removing dependencies on various libraries, and keep a such important process small is already relevant, despite the fact that it will load PAM libraries, making it quite still prone to issues.