Comment by yayachiken
5 hours ago
The paper is not about implementing a general attack that works on all trusting-trust mitigations.
It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.
> It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.
But that seems like quibbling about semantics. Thompson says that if a compromised binary generates a binary, you cannot trust the generated binary.
This does not even have to be gcc, it could be vim. Or strip. Or cat. Or dd.
Or an iop to write data to persistent storage if the firmware of your SSD is compromised.
>The paper is not about implementing a general attack that works on all trusting-trust mitigations.
Then why have section 7.3 'Bootstrappable Builds', that briefly surveys a type of trusting-trust mitigation, and concludes that their method "sustains the attack [...], even after the compiler seed shrinks to a few hundred bytes"?
>It is precisely about showing that you can still propagate backdoored code if the compromised binary in your seed is NOT the compiler.
Whatever this paper is about, it is certainly not precisely about it. But quibbles aside, if that truly is what the authors set out to show, they should probably re-read the transcript, where Ken says "[For demonstration purposes], I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode."