Re:Running the "Reflections on Trusting Trust" Compiler
by codeflo on Thursday October 26, 2023 @05:36AM
(#38023546)
Not if the backdoor is inserted into fopen/mmap calls in such a way that when any executable opens the binary for reading, it sees a version without the backdoor.
Re:Running the "Reflections on Trusting Trust" Compiler
by wizzwizz4 on Thursday October 26, 2023 @06:03AM
(#38023679)
That can't be done without either changing the file size or being really obvious.
Re:Running the "Reflections on Trusting Trust" Compiler
by acdha on Thursday October 26, 2023 @09:52AM
(#38025548)
Malware does that all the time - return different stat() results, change the contents for anything which isn’t execution, etc. It’s detectable but fundamentally you’re in a nasty race since the attacker can use the same tools you do.
Re:Running the "Reflections on Trusting Trust" Compiler
by ericpauley on Thursday October 26, 2023 @07:46AM
(#38024302)
> In theory, any computer tool you use could've already been compromised. You can't be 100% certain (even if you bootstrap from hand-made punchcards, the backdoor could be hidden in hardware).
This is the whole point of Thompson’s lecture, though.
In practice, you can push the likelihood of this down to arbitrarily small levels. Pick a decompiler that's as unrelated to your compiler as you can find. Then pick a second decompiler that's maximally unrelated to both the compiler and the first decompiler. It's highly unlikely all three tools will be backdoored in a fully compatible way.