Recent Features
| |||||||||||||
Security in the 20-teensSecurity in the 20-teensPosted Feb 2, 2010 18:10 UTC (Tue) by droundy (subscriber, #4559)In reply to: Security in the 20-teens by nix Parent article: Security in the 20-teens
It's not enough that the attackers aren't in communication, but rather that
they are mutually ignorant, which seems highly unlikely. I suspect even benevolent compiler writers pay reasonably close attention to the work of other compiler writers, and our malevolent compiler subverters seem likely to pay even more attention to other compilers.
The attacker who inserted a back door into your gcc may have been smart
I suppose anything to raise the bar on the attack would seem worthwhile.
(Log in to post comments)
Countering the trusting trust attack Posted Feb 3, 2010 4:40 UTC (Wed) by dwheeler (guest, #1216) [Link]
> The attacker who inserted a back door into your gcc may have been smart enough to make it also able to insert the same back door into pcc, or any other compiler you can imagine...
Fair enough, but it's harder to subvert multiple organizations, and the defender gets to choose which compiler to use as the second compiler (call it the "trusted" or the "check" compiler). So, choose the one that's unlikely to be subverted the same way. If you don't believe in any, then:
> But it seems like it'd be a more effective approach to write a C compiler in Forth or something else that is simple enough that you could write a compiler for *it* in assembler (or machine code, if you don't trust the assembler...)...
Okay, go ahead and write another compiler yourself. That doesn't conflict with the DDC approach.
Now, you could just use that compiler instead of GCC, but everyone else still has the same problem... how can they trust YOUR compiler? And if you use it to compile another compiler (say GCC) in one step, again, how can anyone else trust the results of that GCC executable?
One answer is to use your C-in-Forth compiler to compile the original compiler source code (say GCC), then use THAT compiler executable to compile the original compiler source code again. Given certain assumptions described in the dissertation, the resulting executable should be exactly the same as your original executable. Once you've shown that they are equal, then that means either both were subverted in the same way, OR that the original executable isn't subverted.
Countering the trusting trust attack Posted Feb 3, 2010 13:25 UTC (Wed) by hppnq (guest, #14462) [Link] how can they trust YOUR compiler? They can't, that's the principle of the Thompson attack.
The suggestion was -- and I think it is the only correct one -- that the compiler used to compile the compiler-compiler does not need to be compiled itself. If it does need to be compiled, the question remains: what compiler will you use to do that?
But can you tell which conclusion is the right one without having to assume that the original executable was not subverted in the first place? It seems to me that a meaningful conclusion can be drawn only when the two executables are not the same, so you can positively identify a subverted compiler.
Countering the trusting trust attack Posted Feb 3, 2010 23:36 UTC (Wed) by dwheeler (guest, #1216) [Link]
> The suggestion was -- and I think it is the only correct one -- that the compiler used to compile the compiler-compiler does not need to be compiled itself. If it does need to be compiled, the question remains: what compiler will you use to do that?
As I discuss in the dissertation, malicious compilers must have triggers and payloads to produce subverted results. If you avoid their triggers and payloads, then it won't matter if they're malicious. For example, a malicious compiler cM may have triggers that affect compilations of its source code, but not for another compiler cQ. So you can use cM to compile the source code of cQ, even though cM is malicious, and have a clean result.
(It's a little more complicated than that; see the dissertation for the gory details.)
Countering the trusting trust attack Posted Feb 4, 2010 7:51 UTC (Thu) by hppnq (guest, #14462) [Link] For example, a malicious compiler cM may have triggers that affect compilations of its source code, but not for another compiler cQ. So you can use cM to compile the source code of cQ, even though cM is malicious, and have a clean result. Eaxactly. But any of the N program-handling components of the build system may be subverted (and not necessarily the same one at each compilation, I suppose), so in order to make a reasonable assumption you have to make sure that none of the N components harbours a payload or trigger. So you have to verify the linker, loader, assembler, kernel, firmware -- i.e., you have to be on completely independent platforms, for both the compilation and verification. I can't see how you can reasonably assure that this is indeed the case, unless you make the assumption that enough components can be trusted. Which you can't, unless you literally assemble everything yourself. ;-) Obviously, practically there is a lot you can do to minimize the chance that someone unleashes the Thompson attack on you. But you can't reduce this chance to zero, so the question is the same as always: is an attacker motivated enough to break through your defense? I am quite sure there are compilers that are not public, to make this particular barrier more difficult. But those are not used to build global financial or even governmental infrastructures. Anyway, I'll shut up now and read the dissertation, it is an interesting topic. Thanks David, and belated congratulations! :-)
|
|||||||||||||