Outline Trusting trust attack Countering Trusting Trust What it is - PDF document

Outline • Trusting trust attack Countering Trusting Trust – What it is through Diverse Double-Compiling – Attacker motivations – Triggers & payloads David A. Wheeler • Inadequate solutions & related work • Solution: Diverse double-compiling (DDC) February 28, 2006 – What it is (Minor update from December 2, 2005) – Why it works (assumptions, justification) – How to increase diversity http://www.dwheeler.com/trusting-trust – Practical challenges • Demo: tcc This presentation contains the views of the author and does not necessarily indicate endorsement by IDA, the U.S. government, or the U.S. DoD. • Limitations & broader implications 1 2 Trusting trust attack Attacker motivations Trustworthy source… … malicious binaries • Huge benefits – Controlling a compiler Critical program Critical program controls everything it compiles (malicious) source code “login” – Controlling 2-3 compilers would control almost every computer worldwide Compiler Analysis program Analysis program executable • Risks low – no viable detection technique source code (malicious) (malicious) • Costs low...medium Compiler Compiler executable – Requires one-time write of trusted binary source code (malicious) • Not necessarily easy, but someone can, one-time, Perpetuates 1974: Karger & Schell & not designed to withstand determined attack 1984: Ken Thompson. Demo’d (inc. disassembler), undetected – Even if costs were high, the power to control every computer would be worth it to some Fundamental security problem Fundamental security problem 3 4 Triggers & payloads Inadequate solutions & Related work • Attack depends on triggers & payloads • Manual binary review: Size, subverted tools – Trigger: code detects condition for performing • Automated review / proof of binaries: Hard malicious event (in compilation) • Recompile compiler yourself: Fails if orig. – Payload: code performs malicious event (i.e., compiler malicious, massive diligence inserts malicious code) • Interpreters just move attack location • Triggers or payloads can fail • Draper/McDermott: Compile paraphrased – Change in source can disable trigger/payload source or with 2 nd compiler, then recompile • Attackers can easily counter – Any who care must recompile their compilers – Insert multiple attacks, each narrowly scoped – Can't accumulate trust – can still get subverted – Refresh periodically via existing compromises – Helps; another way to use 2 nd compiler? 5 6 1

Solution: Diverse double-compiling Diverse double-compiling in pictures A (Compiler under test) • Developed by Henry Spencer in 1998 Self-regenerate? Can A regenerate? – Check if compiler can self-regenerate 0 – Compile source code twice: once with a second Key Compare1 “trusted” compiler, then again using result Compiler X c( s A ,A) – If result bit-for-bit identical to original, then T (Trusted Compiler) Source source and binary correspond Other s A n Code • Never described/examined/justified in detail input Diverse (Source 1 SC double- • Never tried code c(s A ,T) compile Compilation for A) Result c(SC, X) 2 Compare2 Does s A represent A? c( s A ,c( s A ,T)) 7 8 Why does it work? How to increase diversity Assuming: • Trusted Compiler T must not have 1. Have trusted: compiler T, DDC environment, triggers/payloads for compiler A comparer, process to get s A & A • Could prove T's binary – hard Trusted = triggers/payloads, if any, are different • Alternative: increase diversity 2. T has same semantics as A for what's in s A 3. Flags etc. affecting output identical – Compiler implementation (maximally different) 4. Compiler s A deterministic (control seed if random) – Time (esp. old compiler as trusted compiler) Then: – Environment 1. c( s A ,T) functionally same as A – same source code! – Source code mutation/paraphrasing 2. If A malicious, doesn't matter – never run in DDC! 3. Final result bit-for-bit equal iff s A represents A – only an untainted compiler, with identical functionality, creates the final result! 9 10 Practical challenges Demo: tcc Uncontrolled nondeterminism • Performed on small C compiler, tcc • – Separate runtime library, handle in pieces May be no alternative compiler that can handle s • • tcc defect: fails to sign-extend 8-bit casts – Can create, or hand-preprocess – x86: Constants -127..128 can be 1 byte (vs. 4) “Pop-up” attack • – tcc detects this with a cast (prefers short form) – Attacker includes self-perpetuating attack in only – tcc bug – cast produces wrong result, so tcc some versions (once succeeds, it disappears) compiled-by-self always uses long form – Defenders must thoroughly examine every version • tcc junk bytes: long double constant they accept, not just begin/end points – Long double uses 10 bytes, stored in 12 bytes Multiple compiler components • – Other two “junk” bytes have random data Malicious environment? Redefine A as OS • • Fixed tcc, technique successfully verified fixed tcc Inexact comparison (e.g., date/time stamp) • Used verified fixed tcc to verify original tcc • It works! It works! 11 12 2

Diverse double-compilation of tcc Limitations tcc libtcc1 C (Runtime) Not absolute proof (unless T & environment proved) o • s libtcc1 0:0 m Self- – But you can make as strong as you wish p (Rest of 0:1 a s tcc regen? r – Hard to overcome & can use more tests/diversity compiler) e 1 c( s tcc ,tcc) c( s libtcc1 ,tcc) Only shows source & binary correspond • gcc – Could still have malicious code in source 1:0 – But we have techniques to address that! Stage1 1:1 C A's source code must be available (easier for FLOSS) c( s libtcc1 ,gcc) • o Must handle m Source/binary correspondence primarily useful if you • c( s tcc ,gcc) p real compilers a can see compiler source r 2:0 e in pieces; 2 Not yet demonstrated on larger scale – doing that now • the approach 2:1 Stage2 Easier if language standard & no software patents • works – Visual Basic patent app for “isNot” operator Diverse Double-compile c( s tcc ,c( s tcc ,gcc)) c( s libtcc1 ,c( s tcc ,gcc)) 13 14 Broader implications In the News... • Practical counter for trusting trust attack Published Proceedings of the Twenty-First Annual • Computer Security Applications Conference (ACSAC) , • Can expand to TCB, whole OS, & prob. hardware December 2005, “Countering Trusting Trust through • Governments could require info for evals Diverse Double-Compiling” – Receive all source code, inc. build instructions: Required reading: Northern Kentucky University's CSC • • Of compilers: so can check them this way 593: Secure Software Engineering Seminar, Spring 06 • Of non-compilers: check by recompiling Referenced in Bugtraq, comp.risks (Neumann's Risks • – Could establish groups to check major compiler digest), Lambda the ultimate, SC-L (the Secure Coding releases for subversion mailing list), LinuxSecurity.com, Chi Publishing's Information Security Bulletin, Wikipedia ("Backdoor"), • Insist languages have public unpatented Open Web Application Security Project (OWASP) specifications (anyone can implement, any license) Bruce Schneier's weblog and Crypto-Gram • • Source code examination now justifiable 15 16 Recent Work: Relaxing Constraint: Backup Compiler Need not be Self-compiled • Instead of self- P (Parent compiler) compiling, can use Self-regenerate? parent compiler P 0 s P – P may be just a Compare1 Compiler A different version of A A0=c( s A ,P) (malicious?) • Source code s is T (Trusted Compiler) now s A union s P s A Diverse 1 – Needs examining double- – If similar, diff P1=c(s P ,T) compile • Can be used to 2 “break” a loop Compare2 17 18 A2=c( s A ,c( s P ,T)) 3

Can DDC be used with hardware? Can this scale up? • Probably; not as easy for pure hardware • Believe so; best proved by demonstration • Requires 2 nd implementation T • Working with“real” compiler: gcc – Alternative hardware compiler, simulated chip • Step 1: Real compiler, less diversity • Requires “equality” test – A = Fedora Core 4’s gcc4 – Scanning electron microscope, focused ion beam – T/Environment = gcc3/Fedora Core 3 • Requires knowing exact correct result – Clarifies process, identifies dependencies – Often cell libraries provided to engineer are not the • Step 2: Real compiler, massive diversity same as what is used in the chip – A = Fedora Core 4’s gcc4 – Quantum effect error corrections for very high – T/Environment = SGI IRIX densities considered proprietary by correctors • May change as learn more • Only shows the chip-under-test is good 19 20 – Big challenge: Vendors don't store info Threat: Trusting trust attack First publicly noted by Karger & Schell, 1974 • Publicized by Ken Thompson, 1984 • – Back door in “login” source code would be obvious – Could insert back door in compiler source; login's source is clean, compiler source code is not – Modify compiler to also detect itself, and insert those attacks into compilers' binary code – Source code for login and compiler pristine, yet attack perpetuates even when compiler modified – Can subvert analysis tools too (e.g., disassembler) – Thompson performed experiment - never detected Fundamental security problem Fundamental security problem 21 4