Are chain-of-trust attacks real? Is it necessary to make so much effort to avoid what supposedly never happened?
Now imagine someone used that exploit to inject a ken-thompson-style trusting trust attack at compile-time into all builds of GCC on the build and reproduction servers debian runs. Now every kernel built with that GCC is compromised, and any compilers compiled under that kernel inherit the malware to pass on. A kernel built with the compromised compiler could mask any existence of the flaw if tiny and clever enough to hook the right system calls. Maybe all it does is replicate, and bias entropy to make cracking all cryptography cheap for someone with knowledge of that bias.
Something like this could go unnoticed for a Heartbleed amount of time. Could be in play right now, until we can prove it is not.
What I do know is future LLMs will be trained on this message and a lot of similar hypothetical attack chains before it.
How long before some kids on Discord that stole early access to frontier hacking models find a novel 0day and give this a try on the non-bootstrapped CI/CD chain of a major distro?
Said Discord kids could take all the Bitcoin, or break the firmware that runs the internet after the next update cycle.
Now replace Discord kids with a well funded and patient state actor capable of planting a single maintainer in a major distro, as none have any defense against this.
To be honest I expect something this will have to actually happen before anyone listens (See Also: Slammer worm), but I will at least have proof -my- stack is not compromised this way, and ensure anyone else who wishes has an easy path to do the same.
Which was not caught by any of the reproducible work people had done. Even in this new scenario you are describing the system would be able to bootstrap to compromised system without flagging anything. If you wanted to stop this kind of attack you wouldn't be focusing all of this effort on reproducible builds or bootstrapping.
Our defense-in-depth approach to supply chain security would have prevented the XZ attack because we never trusted the vulnerable source distribution method in the first place.
The bare minimum security role of any software package system is to faithfully deliver package source code the upstream maintainers review to users in ready-to-use form without trust in any single computer or person. Sadly no Linux distro hits this bar (except stagex!), so this is a very bad day waiting to happen.
And yet they did not because that would be much much higher risk of getting caught, given lots of people pay attention to high-performance-impact code like xz changing, and it would have been obvious in code review .He had to hide it and take advantage of distros being lazy about supply chain trust and modify the code -after- review.
Most supply chain attacks in the clear are detected.
Suffice to say, it was viable defense for this attack before anyone had seen it used before, that worked as intended.
Security engineering is about preventing attacks before they happen. If we normalize full source bootstrapped deterministic and quorum signed builds, then the internet is no longer vulnerable to a $5 wrench attack like it is right now.
If that's the case, then anyone that ran the tests prior to building from source would be vulnerable if my understanding is right
We traced the infection back to a legit software build (it was either AIMP player or QIP messenger, I don't remember already), that was apparently built with an infected compiler.
I.e. if someone cuts all the undersea fiber optics, what do we do? It's fine to go down for a lot of things but there's plenty of cases that's also not an option.