9 ms·

>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 bri

by fwlr 8d ago

>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."

yayachiken 8d ago
If you actually read how GUIX (what they talk about in section 7.3) is calling a "full source bootstrap", they have brought down the compiler seed to less than 200 bytes, but also they rely on an execution environment that still has 25 Megabytes of unaudited(-able) binary. GUIX is unconfortable about that, but as they name the current process "full source bootstrap" implicitly consider this unaudited execution environment out-of-scope and more of an academic blemish, rather than a real problem: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-... After all you rebuild it together with the world immediately after compiler bootstrap is done. And the utilities in your execution environment do not process the compiler source, so this dependency cannot be a problem, right? The paper precisely addresses this. You cannot handwave away your shell or ELF utilities. They can sustain an attack just like the compiler. > "[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." This is precisely the problem that most people dealing with OPSEC have. If you get "paranoid enough", your threat model always collapses into an unactionable mess where everything is just toast and your only solution is to quit computing and start doing woodwork or something. If everything is potentially compromised then of course the results from the paper become obvious. If your environment is compromised, don't trust its output, duh! If you want to quantify though, under which assumptions, "how much" your environment can be broken without compromising its output, the paper has value. And it seems like real attempts of bootstrapping binaries actually missed a spot.

by fwlr 8d ago

yayachiken 8d ago

If you actually read how GUIX (what they talk about in section 7.3) is calling a "full source bootstrap", they have brought down the compiler seed to less than 200 bytes, but also they rely on an execution environment that still has 25 Megabytes of unaudited(-able) binary. GUIX is unconfortable about that, but as they name the current process "full source bootstrap" implicitly consider this unaudited execution environment out-of-scope and more of an academic blemish, rather than a real problem: https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-building-from-source-all-the-way-down/ https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-... After all you rebuild it together with the world immediately after compiler bootstrap is done. And the utilities in your execution environment do not process the compiler source, so this dependency cannot be a problem, right? The paper precisely addresses this. You cannot handwave away your shell or ELF utilities. They can sustain an attack just like the compiler. > "[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." This is precisely the problem that most people dealing with OPSEC have. If you get "paranoid enough", your threat model always collapses into an unactionable mess where everything is just toast and your only solution is to quit computing and start doing woodwork or something. If everything is potentially compromised then of course the results from the paper become obvious. If your environment is compromised, don't trust its output, duh! If you want to quantify though, under which assumptions, "how much" your environment can be broken without compromising its output, the paper has value. And it seems like real attempts of bootstrapping binaries actually missed a spot.