3 ms·

This is really interesting in terms of mitigating trusting trust attacks.

benj111 3y ago
Maybe? You still have to trust the original compiler, and you still can't rely on reading the source. You just have to hope that the simple compiler is simple enough to read at the machine code level, and trust your file system / hex viewer / text editor.
- throwawayneio31 3y ago
  No, it’s possible to fully mitigate it. See https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/
  - benj111 3y ago
    that assumes the other compilers aren't compromised. lets say gcc is compromised. if it detects its compiling a compiler it inserts a back door routine, if it detects it's compiling an os, it inserts a backdoor, if it detects its compiling a file system it inserts code to hide that back door and prevent it being shown to the user, when a user accesses those files. if you compile tinycc with gcc, youve lost. if you compile tinycc with anything thats been compiled by gcc youve lost. you arent going to detect it by looking at the source code, you arent going to detect it looking at the binary, you would have to look at the running executable, and hope that the attackers didn't take my example one step further. you basically need to make your own trusted stack. but then anyone else that uses that stack has to trust you. You can't fully mitigate it, all you can do is trust that all the people building their own trusted stacks aren't in on it, and are competent. But then we're back to trust again.
    - Karellen 3y ago
      > if it detects its compiling a compiler it inserts a back door routine, That's going to be hard. If you're compiling yourself, sure, you know how the compiler is structured and what the source code looks like, so it's easy to spot the point to add the hidden backdoors to. But inserting the backdoors into an arbitrary compiler? That may be structured differently, or use a completely different set of intermediate representations? Or even just uses `camelCase()` instead of `lower_underscores()` for function naming? I'm not sure a generic backdoored compiler would be an option. I think you'd need separate payloads for, say, gcc and tinycc. But then the problem becomes, how do you add a new backdoor for a compiler that was released after yours, without anyone noticing? If you do a 3-stage bootstrap of GCC, the end result will be noticeably different if someone started with a pre-new-backdoor binary compiler than with a post-new-backdoor binary compiler.
    - Aerbil313 3y ago
      I assume you’ve skimmed the paper, because it addresses and mitigates exactly the scenario you’re describing. I can understand if you assume that it’s impossible to achieve an uncompromised system from a totally compromised one, I did the same mistake at first. The solution really seems like a magic trick.
- mananaysiempre 3y ago
  The simple compiler mes/stage0 is using is ~300 bytes and comes with commented assembly source, so it should be, yeah. Then there’s a chain of progressively more capable ones (the next couple are still commented machine code, but at least you don’t have to poke at them with a hex editor).

Maybe? You still have to trust the original compiler, and you still can't rely on reading the source. You just have to hope that the simple compiler is simple enough to read at the machine code level, and trust your file system / hex viewer / text editor.

throwawayneio31 3y ago
No, it’s possible to fully mitigate it. See https://dwheeler.com/trusting-trust/ https://dwheeler.com/trusting-trust/
- benj111 3y ago
  that assumes the other compilers aren't compromised. lets say gcc is compromised. if it detects its compiling a compiler it inserts a back door routine, if it detects it's compiling an os, it inserts a backdoor, if it detects its compiling a file system it inserts code to hide that back door and prevent it being shown to the user, when a user accesses those files. if you compile tinycc with gcc, youve lost. if you compile tinycc with anything thats been compiled by gcc youve lost. you arent going to detect it by looking at the source code, you arent going to detect it looking at the binary, you would have to look at the running executable, and hope that the attackers didn't take my example one step further. you basically need to make your own trusted stack. but then anyone else that uses that stack has to trust you. You can't fully mitigate it, all you can do is trust that all the people building their own trusted stacks aren't in on it, and are competent. But then we're back to trust again.
  - Karellen 3y ago
    > if it detects its compiling a compiler it inserts a back door routine, That's going to be hard. If you're compiling yourself, sure, you know how the compiler is structured and what the source code looks like, so it's easy to spot the point to add the hidden backdoors to. But inserting the backdoors into an arbitrary compiler? That may be structured differently, or use a completely different set of intermediate representations? Or even just uses `camelCase()` instead of `lower_underscores()` for function naming? I'm not sure a generic backdoored compiler would be an option. I think you'd need separate payloads for, say, gcc and tinycc. But then the problem becomes, how do you add a new backdoor for a compiler that was released after yours, without anyone noticing? If you do a 3-stage bootstrap of GCC, the end result will be noticeably different if someone started with a pre-new-backdoor binary compiler than with a post-new-backdoor binary compiler.
  - Aerbil313 3y ago
    I assume you’ve skimmed the paper, because it addresses and mitigates exactly the scenario you’re describing. I can understand if you assume that it’s impossible to achieve an uncompromised system from a totally compromised one, I did the same mistake at first. The solution really seems like a magic trick.
mananaysiempre 3y ago
The simple compiler mes/stage0 is using is ~300 bytes and comes with commented assembly source, so it should be, yeah. Then there’s a chain of progressively more capable ones (the next couple are still commented machine code, but at least you don’t have to poke at them with a hex editor).