Countering Trusting Trust with Diverse Double-Compiling (by David A Wheeler)

1. Countering Trusting Trust with Diverse Double-Compiling(by David A Wheeler) Dan Frohlich

2. Trusting Trust • “…compilers can be subverted to insert malicious Trojan horses into critical software, including themselves.” • Thompson “Reflection on Trusting Trust”

3. What does Trusting Trust do? • The attack uses 2 triggers: 1 to subvert system access and 1 to propagate the attack when re-compiled

4. Features of Trusting Trust Attack. • Trigger • A condition determined by an attacker in which a malicious event is to occur • Payload • The code that performs the malicious event • The inserted code and the code that causes the insertions • Non-Discovery • Binary files are non-transparent. • Therefore the attack is difficult to identify.

5. The threat of Trusting Trust. • An attacker who subverted a few of the most widely-used operating systems could effectively control, directly or indirectly almost every computer in existence. • This could be aggravated by a monoculture in computing platforms. • Wheeler claims that many persons in the community believe that the risk of these kinds of attacks are increasing.

6. Detecting the Trusting Trust Attack is problematic. • Security evaluations examine source code under the assumption that it accurately represents the product being examined. • But, an attacker who can control the compiler binary can render source code evaluations worthless. • For source code security evaluations to be strongly credible, there needs to be a way to justify that the source code being examined accurately represents the files being executed.

7. Diverse Double-Compiling (defined.) • In DDC, if the final result is bit-for-bit identical to the original compiler binary, then the compiler source code accurately represents the binary. • c(sA, A) == c(sA, c(sA, T )) • c(s,X) is the result of compiling s with X. • sA is the untrusted compiler source • A is the untrusted compiler • T is the trusted compiler

8. c(sA, A) == c(sA, c(sA, T ))

9. Inadequate solutions to Trusting Trust defense • Manually compare binary to source • Compare binary to source by an automated process • Use second compiler • test semantic equivalence of the two binaries. • Only receive source • compile everything yourself • Interpreted languages • Simply changes the target of attack.

10. Why not compare the binary to the source? • Manual comparison is impractical due to resource requirements. • Automated comparison is difficult due to optimizing compilers. • Doesn’t DDC suffer from the very same issues?

11. Use a trusted compiler. • Use second compiler and compare binaries. • Testing the semantic equivalence of the two binaries is very difficult. • Only receive source / compile yourself • fails when receivers compiler is already malicious. • But this only fails if receiver compiler T has a trigger on A. • Doesn’t DDC have the same issue if T has a trigger on A?

12. The problems with the other solutions to Trusting Trust • These approaches require the defender to insert themselves into the compiler creation process (to recompile it themselves before using it. This is often impractical. • But with DDC I have to compile it twice then debug it, then compare the binaries for equivalence. How is this an improvement?

13. Why use DDC to detect Trusting trust? • It can be completely automated. • After debugging each compiler involved. • Doesn’t require proofs • Doesn’t guarantee the attack will be found either. • Reveals defects in the compilers involved. • A beneficial side effect, but not why I’m doing this. • Can be expanded to cover all software running on a system.

14. Questions? • Is there any value to discovering this attack as opposed to blindly destroying it with the trusted compiler alternative?