d06b125bc2c9f8789813a75c65763b7a.ppt
- Количество слайдов: 17
Countering 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 ¡ 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? ¡
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
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
Analysis of Threat – Attacker Motivation ¡ Potential benefits of a “trusting trust” attack include: l l l 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.
Analysis of Threat – Attacker Motivation ¡ Such an attack requires: l l l Knowledge of compilers The effort involved with creating an attack Access to the compiler binary
Triggers, payloads, and non-discovery ¡ A successful attack depends on three things: l l l Triggers Payloads Non-discovery
Triggers, payloads, and non-discovery ¡ For a trusting trust attack to be valuable, there must be at least two triggers: l l 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
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
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
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, T)) Finally compare c(SA, T)), A, and c(SA, T) If all three are identical, we can say that SA accurately reflects A
Justification ¡ To justify the DDC technique, we must make some assumptions: l l 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, T)) The compiler defined by SA should be deterministic given only its inputs, and not use or write undefined values
Methods to increase diversity ¡ Diversity in compiler implementation l ¡ Diversity in time l ¡ Compiler T developed long before compiler A, and they do not share a common implementation heritage Diversity in environment l ¡ Compiler T’s binary should be for a completely different implementation than of compiler A Compiler T could generate code for a different environment, c(SA, T) could run on a different environment Diversity in source code input l Use mutations of compiler A’s source code as the input to the first stage of DDC
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 ¡
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 ¡
Cited Works ¡ Countering Trust through Diverse Double-Compiling by David A Wheeler: http: //www. acsaadmin. org/2005/papers/47. pdf
Questions?
d06b125bc2c9f8789813a75c65763b7a.ppt