1. r Enabling Trusted Software Integrity Darko Kirovski Microsoft Research Milenko Drinić Miodrag Potkonjak Computer Science Department University of California, Los Angeles

2. Problem Description

3. Buffer Overrun  Goal –Explore improperly implemented I/O –Divert execution to attack code  Simplest variant – Stack smashing –“Smashing The Stack For Fun And Profit” by Aleph One (aleph1@underground.org), Phrack 49, 1996.aleph1@underground.org  Numerous variants explore different vulnerabilities –Tutorials on the Web with bug descriptions –setuid() – Chen, Wagner, Dean, 2002.

4. What Can Be Done?  StackGuard – Cowan et al., 1998 –Dummy value next to return address  Bounds checking for all pointers – Jones, Kelly, 1995 –Slow in pointer-intensive software  Static analysis – Wagner, 2000 –Verify all buffers – promising idea –Too many false alarms –Need to be resolved manually

5. Intrusion Prevention  Current approaches –Intrusion detection  PREVENT rather than DETECT is easier  Intrusion prevention system –Adversary must solve a computationally difficult task to run programs in high priority  Two types of binaries –Ordinary –Touched with a security wand  Run-time verification

6. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

7. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

9. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

10. Software Installation  Installer is on- chip or on an EPROM with verified contents  Single process  I/O – memory mapped  Interrupts disabled  Used registers, memory overwritten  ~ BOOT on PCs GOAL: embed constraints w/o revealing CPUID.

11. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

12. Example: Instruction Scheduling

13. How the Bitstream Reorders Ops?

14. –Examples Instruction rescheduling Register assignment Basic block reordering Conditional branch selection Filling unused opcode fields Toggling signs of operands Constraint Embedding Techniques  Entropy of program representation is high  Reduce entropy w/ constraints for 50+ bits with preserved performance  Exact entropy reduction unique for each CPUID  Constraint types –Requirements High entropy Functional transparency Transformation invariance Effective implementation Low performance overhead

15. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

16. Run-time Code Verification  ARM instruction set and simulated system  50 cycles  20K gates  HW support? Cache line

17. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

18. How to Break the System?  Cryptographically secure keyed MAC –Hard to extract CPUID from working-copies –Hard to create an I-block with CPUID constraints satisfied w/o the CPUID  Patch low entropy instruction blocks –I-block with low entropy? Example: I-block = one instruction and all other NOPS –Hardware must detect I-blocks with low entropy Count and limit domain cardinality Done during domain ordering  Patch I-blocks from working copies –Difficult? Hard to evaluate w/o a lot of software

19. Outline  How the system works?  Software installation  Example of constraint embedding  Run-time verification  How to break the system?  Effect on performance

20. Performance  Embedded bits of entropy  Performance effect –13-25% overhead –7-17% with a cache that logs TI-hashes  Simulated w/ ARMulator  ARM instruction set  MediaBench suite

21. Summary  Intrusion prevention  On-line software verification for authenticity  Keyed message authentication code –Stored as footer –Stored as constraints 50% decrease in code size overhead  Public and trusted execution mode  Relatively hi/lo performance overhead –No hardware acceleration –20% - sets back Moore’s Law 4.5 months