Comment by torginus
I just had a thought about dependency chain attacks - has there been any example where instead of overtly compromising the code, they injected an exploitable bug?
Though I guess it'd be hard to prove intent in this case.
I just had a thought about dependency chain attacks - has there been any example where instead of overtly compromising the code, they injected an exploitable bug?
Though I guess it'd be hard to prove intent in this case.
It's also worth noting that the xz exploit didn't even live in the xz source, it was added to the source by the attacker before uploading it to the package build farms. With most of the current package repositories, there's not even an expectation that the bundles you get are derived from a particular tag or commit hash, let alone a detailed chain of custody. I remember RPM in the old days made a big deal out of "pristine sources" to which patches would be applied, but it still has no way to prove or enforce that claim.
These are just backdoors as a vulnerability class. It does happen occasionally even in high quality widely used libraries, but it's very rare and usually quite sophisticated (e.g. https://en.wikipedia.org/wiki/XZ_Utils_backdoor in 2024). A lot of these attacks, even when highly sophisticated, only really work when the attack payload can be hidden in a binary--it's very very hard to insert a useful backdoor into the source code of an actively maintained project that receives regular code reviews without anyone noticing (which is not to say it's impossible).