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

Problem Description

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 Phrack 49,  Numerous variants explore different vulnerabilities –Tutorials on the Web with bug descriptions –setuid() – Chen, Wagner, Dean, 2002.

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

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

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

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

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

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.

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

Example: Instruction Scheduling

How the Bitstream Reorders Ops?

–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

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

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

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

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

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

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

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