Evaluating SFI for a CISC Architecture by Stephen McCamant and Greg - - PowerPoint PPT Presentation

CSE598a/544 - Advanced Systems Security Page

Evaluating SFI for a CISC Architecture

Presented by William Enck CSE598a/544 - Advanced Systems Security April 24, 2007

1

by Stephen McCamant and Greg Morrisett USENIX Security Symposium 2006

CSE598a/544 - Advanced Systems Security Page

A Reoccurring Topic

• Today’s topic: Buffer Overflows
• Why do we keep talking about them?
• A quick review of malcode prevention:
• Sandboxing
• Syscall IDS
• Randomization
• Canaries
• etc.
• We are not going to talk about buffer
• verflows per se, rather another technique

that can help stop attacks, one of which is buffer overflows

2

Top of Stack

Return Address

variables

buffer[n-1] buffer[...] buffer[0]

0x00...00 0xFF...FF

Stack Growth Buffer Growth

... ...

CSE598a/544 - Advanced Systems Security Page

A Practical Approach

• A Two-Step Process
• Rewrite application binaries
• Consume assembly code (this is not a compiler trick)
• Verify the rewrite was successful
• can be done at load time

3

“We do not mind if the verifier fails to recognize that some programs have the safety property, as long as whenever it concludes that on does, it is correct.”

CSE598a/544 - Advanced Systems Security Page

Software Fault Isolation

• Basic idea: prevent potentially unsafe instructions from

executing with improper arguments

• down to the granularity of memory writes
• How do the goals differ from other

techniques?

• Limitations:
• Typically slow
• CISC is tough

4

“SFI does not provide general protection against attacks on the untrusted code; it simply contains those attacks within the component”

CSE598a/544 - Advanced Systems Security Page

The x86 Architecture

• You can’t live with it,

you can’t live without it

• x86 is the de-facto standard that is

not going away

• CISC Architectures have:
• instructions vary in length
• RISC typically has a “4-byte stream”
• small number of registers
• Previous SFI techniques required five

5

CSE598a/544 - Advanced Systems Security Page

Normalizing CISC

• Instruction “streams” are used by previous SFI

techniques to verify branch target addresses

• CISC has variable length instructions
• add “nop” padding to recreate sanity
• no instruction crosses the 16-byte chunk boundary
• The start of every 16-bytes is an instruction

(“psuedo-stream”)

• What is the cost of this addition?
• Largest percentage of performance overhead
• From a storage perspective, binaries increase

by 50-100% (but easily compressible)

• No one ever said security was free

6

CSE598a/544 - Advanced Systems Security Page

Efficient Protection

• Make use of architecture and implementation specifics
• Use as few “special” registers as possible (%ebp)
• Smart memory range checking
• Frame pointer (%ebp) only set at start of function
• check on set
• Stack pointer (%esp) frequently modified
• This one is a little more tricky (problematic in related work)
• check before jump
• Efficient address “checking” with bitwise and
• code regions with simple higher order bits
• use mask to ensure the address is where you want it to be
• Modern x86 processors keep shadow stacks for branch

prediction, therefore, we want to keep ret instructions

7

CSE598a/544 - Advanced Systems Security Page

Formal Analysis

• Not something you see every day
• The ACL2 theorem-proving system

acts on Lisp implementations of a model system

• Implemented an x86 simulator
• Proves verifier achieves safety goals
• The rewriter was not analyzed

8

CSE598a/544 - Advanced Systems Security Page

Back to Buffer Overflows

• What does all of this do for buffer overflows?
• Binaries verified to provide fault containment
• The verifier has been verified
• They solved buffer overflows, right?
• Is the model correct?
• Is containment the answer?
• Does this work for real programs?
• Apache, Bind? OpenSSH?

9

CSE598a/544 - Advanced Systems Security Page

Take-away

• A lot of interesting optimizations have been applied

to make a previously discounted idea applicable to real systems

• Knowing what an arbitrary program will do is

impossible;

• however, it may be good enough to be sure that a program

with specific properties will act in specific ways.

10