4 ms·

That does introduce the possibility of a Trusting Trust attack where the original C program could compile the compiler or runtime with a vulnerability that pers

by pests 2y ago

That does introduce the possibility of a Trusting Trust attack where the original C program could compile the compiler or runtime with a vulnerability that persists until the final compile. Or a similar vector to the xz attack where everything looks completely normal, except for this old script that was subtly changed and if you bootstrap from c you are vulnerable but if you bootstrapped from the language source itself you are good.

Isamu 2y ago
>but if you bootstrapped from the language source itself you are good No, that’s exactly what Ken Thompson was describing in Trusting Trust. You always have to bootstrap the compiler, but once you do, you use the compiler to compile itself and all future versions. So you use that circularity to hide the evidence of a back door in the compiler. It applies to all bootstrapped languages.
kazinator 2y ago
You cannot get around the Ken Thompson problem because all bootstrapping starts with some trusted binary that compiles your level 0 sources. Now, sure, if your chain does not involve C, then it is immune to a compromised C compilers; how could C compilers do anything to it, that are not installed or run? However, you're vulnerable to a doctored binary of your language. Bootstrapping your Language X from C helps you here also, for multiple reasons. Reason 1: there is no recursive cycle when you externally boostrap from another language. Even if a C compiler is doctored in order to recognize that it's boostrapping Language X, and do something malicious, that malicious thing will not propagate to new Language X installations. Reason being that the build output of Language X is not used for further bootstrapping new Language X instances. The other language is always used for boostrapping. All proliferation of the hack has to propagate through the ecosystem of that other language. Reason 2: Language X is less popular than the boostrapping language, which makes its ecosystem vulnerable. If a vulnerable language with a tiny ecosystem is boostrapped using ready-made binaries of itself, those binaries are likely only available from one site. If those are infected, it's game over. Reason 3: Language X development does not develop the host language (such as C). C is not of interest to the Language X project, and can be conservatively used, so that Language X will build fine with a 20 year old GCC. Even if a bad actor attacks Language X by getting malicious code upstreamed into GCC, that attack won't appear in old versions of GCC. (By the same token, Language X written in Language X could also use a conservative dialect of Language X for boostrapping, so that a many-years-old implementation of it with a widely known SHA-256 can be used.)
- medo-bear 2y ago
  > However, you're vulnerable to a doctored binary of your language. I think obscure language X being written in language X is more of a security benefit because it is more likely that a much greater portion of those who use language X are better able to recognise weirdness than if there are parts of your computing environment that are essentially blackboxes.
- pests 2y ago
  Yep I slipped up there. There is a defense against the trusting trust attack. It basically involves using two different compilers and checking their output matches. You can find the article about it if you search.
- Karellen 2y ago
  > You cannot get around the Ken Thompson problem I thought Dr. David A. Wheeler's 2009 doctoral dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling" had been generally accepted as proof that you could? https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/

by pests 2y ago

Isamu 2y ago

>but if you bootstrapped from the language source itself you are good No, that’s exactly what Ken Thompson was describing in Trusting Trust. You always have to bootstrap the compiler, but once you do, you use the compiler to compile itself and all future versions. So you use that circularity to hide the evidence of a back door in the compiler. It applies to all bootstrapped languages.

kazinator 2y ago

You cannot get around the Ken Thompson problem because all bootstrapping starts with some trusted binary that compiles your level 0 sources. Now, sure, if your chain does not involve C, then it is immune to a compromised C compilers; how could C compilers do anything to it, that are not installed or run? However, you're vulnerable to a doctored binary of your language. Bootstrapping your Language X from C helps you here also, for multiple reasons. Reason 1: there is no recursive cycle when you externally boostrap from another language. Even if a C compiler is doctored in order to recognize that it's boostrapping Language X, and do something malicious, that malicious thing will not propagate to new Language X installations. Reason being that the build output of Language X is not used for further bootstrapping new Language X instances. The other language is always used for boostrapping. All proliferation of the hack has to propagate through the ecosystem of that other language. Reason 2: Language X is less popular than the boostrapping language, which makes its ecosystem vulnerable. If a vulnerable language with a tiny ecosystem is boostrapped using ready-made binaries of itself, those binaries are likely only available from one site. If those are infected, it's game over. Reason 3: Language X development does not develop the host language (such as C). C is not of interest to the Language X project, and can be conservatively used, so that Language X will build fine with a 20 year old GCC. Even if a bad actor attacks Language X by getting malicious code upstreamed into GCC, that attack won't appear in old versions of GCC. (By the same token, Language X written in Language X could also use a conservative dialect of Language X for boostrapping, so that a many-years-old implementation of it with a widely known SHA-256 can be used.)

medo-bear 2y ago
> However, you're vulnerable to a doctored binary of your language. I think obscure language X being written in language X is more of a security benefit because it is more likely that a much greater portion of those who use language X are better able to recognise weirdness than if there are parts of your computing environment that are essentially blackboxes.
pests 2y ago
Yep I slipped up there. There is a defense against the trusting trust attack. It basically involves using two different compilers and checking their output matches. You can find the article about it if you search.
Karellen 2y ago
> You cannot get around the Ken Thompson problem I thought Dr. David A. Wheeler's 2009 doctoral dissertation "Fully Countering Trusting Trust through Diverse Double-Compiling" had been generally accepted as proof that you could? https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/