Let’s Stop Beating Dead Horses, and Start Beating Trojan Horses!

David Evans

www.cs.virginia.edu/~evans/ INFOSEC Malicious Code Workshop San Antonio, 13 January 2000 University of Virginia Department of Computer Science Charlottesville, VA

Analogy: Security

• Cryptography – Fun to do research in, lots of cool math problems, opportunities to dazzle people with your brilliance, etc.

• But, 99.9999% of break ins do not involve attack on sensible cryptography – Guessing passwords and stealing keys – Back doors, buffer overflows – Ignorant implementers choosing bad cryptography [Netscape Navigator Mail] 13 January 2000 Dead Horses, Trojan Horses 2

Structure of Argument

Agree Low-level code safety (isolation) is the wrong focus Disagree PCC is not a realistic solution for the real problems in the foreseeable future PCC is not the most promising solution for low level code safety Lots of useful research and results coming from PCC, but realistic solution to malicious code won’t be one of them.

13 January 2000 Dead Horses, Trojan Horses 3

Low-level code safety

• Type safety, memory safety, control flow safety [Kozen98] • All high-level code safety depends on it • Many known pretty good solutions: separate processes, SFI, interpreter • Very few real attacks exploit low-level code safety vulnerabilities – One exception: buffer overflows • Many known solutions to this • Just need to sue vendors to get them implemented 13 January 2000 Dead Horses, Trojan Horses 4

High-Level Code Safety

• Enforcement is (embarrassingly) easy – Reference monitors (since 1970s) – Can enforce most useful policies [Schneider98] – Performance penalty is small • Writing good policies is the hard part – Better ways to define policies – Ways to reason about properties of policies – Ideas for the right policies for different scenarios – Ways to develop, reason about, and test distributed policies 13 January 2000 Dead Horses, Trojan Horses 5

Proofs

All possible executions

No run-time costs

Checking integrated into code Excruciatingly difficult

Reference Monitors

Current execution so far Monitoring and calling overhead

Checking separate from code Trivially easy

Vendor sets policy

Consumer sets policy

13 January 2000 Dead Horses, Trojan Horses 6

Fortune Cookie

can

worth much.” Fortune cookie quoted on Peter’s web page

• True for all users • True for all executions • Exception: Low-level code safety

13 January 2000 Dead Horses, Trojan Horses 7

Reasons you might prefer PCC

• Run-time performance?

– Amortizes additional download and verification time only rarely – SFI Performance penalty: ~5% • If you care, pay $20 more for a better processor or wait 5 weeks • Smaller TCB?

– Not really smaller: twice as big as SFI (Touchstone VCGen+checker – 8300 lines / MisFiT x86 SFI implementation – 4500 lines) • You are a vendor who cares more about quality than time to market (not really PCC) 13 January 2000 Dead Horses, Trojan Horses 8