4 ms·

I also think they’ve shortchanged the bootstrap build mitigation. They write: A utility such as strip sustains the attack whenever a tampered instance part

by fwlr 9d ago

I also think they’ve shortchanged the bootstrap build mitigation. They write: A utility such as strip sustains the attack whenever a tampered instance participates in the rebuild, even after the compiler seed shrinks to a few hundred bytes. Well, yes, if you presuppose your modified binary is used, then you will find that your attack continues, but that’s only because “P iff P” is a logical tautology. It would be true even when the seed shrinks to 0 bytes, or shrinks to a negative number of bytes, or shrinks into a miniature poodle and tap-dances across your keyboard. The question that should have been addressed is “does the tampered instance participate in the build?”, and the whole point of these minimal-byte “seed” bootstraps is that they are just enough bytes of executable to do everything else from the source. So, no, the tampered instance won’t be participating in the build. We might even deploy our own tautology and say that if a pre-existing tainted binary participates in a build, then that build was not a bootstrap build, and therefore all bootstrap builds are in fact perfectly and definitionally immune to the attack. Honestly, this whole paper kinda reads like an academic version of a slop CVE.

yayachiken 9d 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.
- 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.
- tetha 8d ago
  > 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.

by fwlr 9d ago

yayachiken 9d 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.

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.
tetha 8d ago
> 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.