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:

17. Questions?