1 / 17

Countering Trusting Trust through Diverse Double-Compiling

Countering Trusting Trust through Diverse Double-Compiling. Russ Giordano CSC 8410 Operating Systems 4/23/2007. Product Security Evaluations. Generally, it is assumed that a check of source code is enough

Download Presentation

Countering Trusting Trust through Diverse Double-Compiling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related