3 ms·

Countermeasures to this sort of attack are already bog-standard in high reliability systems. You just verify that the compiler output corresponds to the source

• theamk 5y ago
  That's the right link? One of the three requirements is "there is additional code that is not traceable to source code" -- but that's not the case here at all. Every emitted assembly line has a corresponding source code line -- at least as far as compiler and verification systems are concerned. Users see something else, but build/testing system does not know about that. To follow more, I do wonder what is the threat model for a system like this here... because your page talks about "generates additional code that is not directly traceable to Source Code statements". So if the backdoored compiler emits something like: # Source line: if (user_class == ADMIN) { cmp $user_class, V_ADMIN jeq admin_stuff cmp $user_password, "please_let_me_in" jeq admin_stuff ... then your fancy verification system will see that that block of assembly is directly traceable to source code statement (because compiler said so!) and will let it through. Looks like that will be as suspectable to "trusting trust" attack as any other system... as long as attacker does not forget to forge metadata as well as object code.
  • Veserv 5y ago
    The human verifier in the process will trivially determine that the compiler output does not match the source code. Your reasoning only applies to a process lax enough to just assume the compiler can be trusted. This also ignores the testing requirements that require the tests to exercise the source code and its corresponding output. It would be quite amazing to have a rewrite that not only causes malicious code to be generated, but also cause the malicious code to pass the independently written tests while ensuring the tests fully exercise all branches and conditions in the malicious code.