Countering Trusting Trust through Diverse Double-Compiling

1. Countering Trusting Trust through Diverse Double-Compiling Russ Giordano CSC 8410 Operating Systems 4/23/2007

2. Product Security Evaluations • Generally, it is assumed that a check of source code is enough • Check every time the source code is recompiled to see if you get the same binary results • But what happens if malicious code has been inserted into the binary files of the compiler itself?

3. Inadequate Solutions • Compiler binary files could be manually compared with their source code • Automating the comparison of compiler source to compiler binary • Compile source code with a second compiler • Receivers could require that they only receive source code • Programs can be written in interpreted languages

4. What is Trusting Trust? • When an attacker modifies one or more binaries so that the compilation process inserts different code than would be expected • Recompilation of the compiler still results in the reinsertion of malicious code • Original source code can be examined without finding the attack, and the compiler itself can be recompiled without removing the attack

5. Analysis of Threat – Attacker Motivation • Potential benefits of a “trusting trust” attack include: • Complete control of all systems compiled by affected binary [and it’s descendants] • Backdoor passwords/logins that allow unlimited privileges on entire classes of systems • For a widely-used compiler, or one used to compile a widely-used program or operating system, an attack could result in global control over banks, financial markets, military systems etc.

6. Analysis of Threat – Attacker Motivation • Such an attack requires: • Knowledge of compilers • The effort involved with creating an attack • Access to the compiler binary

7. Triggers, payloads, and non-discovery • A successful attack depends on three things: • Triggers • Payloads • Non-discovery

8. Triggers, payloads, and non-discovery • For a trusting trust attack to be valuable, there must be at least two triggers: • One that causes a malicious attack that provides some direct value to the attack • One that propagates the ability to attack in future versions of the code

9. Triggers, payloads, and non-discovery • The “fragility” of an attack is the susceptibility of the attack to failure • Fragility of an attack can be countered by an attacker by incorporating many narrowly defined triggers and payloads • There may be enough vulnerabilities in the resulting system to allow an attack to re-enter a compiler at will to add new/modify existing triggers and payloads

10. Diverse Double Compiling • To perform Diverse Double Compiling [DDC], you recompile a compiler’s source code twice: once with a second “trusted” compiler, and then again using the result of the first compilation. • Check if the final result exactly matches the original compiler binary • In order to perform DDC on a compiler, it must be able to self-regenerate

11. Diverse Double Compiling • Start by using a trusted compiler T to compile the source code SA of an untrusted complier A resulting in c(SA,T) • Next, use c(SA,T) to compile SA again, resulting in c(SA,c(SA,T)) • Finally compare c(SA,c(SA,T)), A, and c(SA,T)If all three are identical, we can say that SA accurately reflects A

12. Justification • To justify the DDC technique, we must make some assumptions: • We must have a trusted compilation process T, comparer, and environments to perform all of the actions involved with DDC • T must have the same semantics for the same constructs as A • Information that affects the output of compilation must be semantically identical when generating c(SA,T), and c(SA,c(SA,T)) • The compiler defined by SA should be deterministic given only its inputs, and not use or write undefined values

13. Methods to increase diversity • Diversity in compiler implementation • Compiler T’s binary should be for a completely different implementation than of compiler A • Diversity in time • Compiler T developed long before compiler A, and they do not share a common implementation heritage • Diversity in environment • Compiler T could generate code for a different environment, c(SA,T) could run on a different environment • Diversity in source code input • Use mutations of compiler A’s source code as the input to the first stage of DDC

14. Ramifications • DDC technique has many strengths: can be complete automated, applied to any common language, and does not require the use of complex mathematical proofs • Unintentional defects in either compiler are also detected by the technique

15. Ramifications • The DDC only shows that the source code corresponds with a given compiler’s binary [nothing is hidden in the code] • The binary may have errors or malevolent code; the DDC technique simply ensures that these errors and malevolent code can be found by examining the source code

16. Cited Works • Countering Trusting Trust through Diverse Double-Compiling by David A Wheeler:http://www.acsa-admin.org/2005/papers/47.pdf

17. Questions?