Memory Exploits & Defenses

Presenter: Kevin Snow

 What is the threat?

How do we defend ourselves?

What is the threat?

 Stack Smashing

 Return-to-libc

 Format String Error

 Heap Overflow
Generic Stack Frame

Caller

Callee
Stack Smashing

Goal:
Point return address to our buffer,
which contains executable code
 Stack Smashing

void f(char *p){

char x[128];
strcpy(x, p);
}

Our Stack Generic Stack

return-to-libc

Goal:
Point return address to an existing
library function
return-to-libc

f(){
g(&foo);
}

g(char *x){
char y [SZ];
scanf(y);
}

Linked libraries often have useful strings lying around

Format String Errors

 Goal: Take advantage of printf() family of

functions

Good: Good:
printf(“%d”, num); printf(“%s”, myString);
Bad: Bad:
printf(“%d”); printf(myString);
Format String Errors

Goal:
Craft a special string that can write
arbitrary values to arbitrary
addresses
Format String Errors

f(){
int x; int y;
char s[128];
scanf(s);
printf(s);
}
Heap Overflow

Goal:
Overwrite function pointers on heap
to point to injected code
Heap Overflow

 C++ objects are allocated on the heap

 Addresses of these object’s functions
stored on the heap (vfptr’s)
 Overflow heap variable and overwrite
these vfptr’s
 When function is invoked, our code is
executed instead
How do we defend ourselves?

 Canary

 Library Wrapper

 Shadow Stack

 W⊕X Pages
Canary

•Place “Canary” before return address

• terminator (0x00, 0x0a, 0x0d)

• random
•Check validity of Canary before
returning
Canary (2)

 This is a great solution, right?

 Wrong! What about format string attacks?
Library Wrappers (libsafe)

 Replace know vulnerable function calls

with ‘safe’ versions
 ‘Safe’ versions ensure nothing is written
past the current stack frame
Library Wrappers (libsafe)
 If we can not get past the stack frame,
we can’t exploit anything?

 Many problems:
• User written input loops not protected
• We can still corrupt local variables
• We can still do a heap overflow
Shadow Stacks

•Keeps extra copy of return address in

separate memory space

•Onlyallows a return if address

matches up
Shadow Stacks (2)

 So, this is the foolproof solution?

• Limitations: Does not protect other data

• Local variables
• Heap overflow overwrites function pointers
W⊕X Pages

•Idea: if memory is writable, it should

not be executable

•Does not allow stack to be executed

• Try to thwart Stack-smashing

W⊕X Pages

 Game over, we can not execute injected

code

 Wait! We can return-to-libc instead

Defense Conclusions

 No defense protects against all memory

exploits

 We need a defense-in-breadth approach

Two Countermeasures

 Instruction Set Randomization

 Address Space Randomization

 Countering Code-Injection Attacks With
Instruction-Set Randomization
Gaurav S. Kc et. Al.
10th ACM International Conference on Computer
and Communications Security (CCS)

Intrusion detection: Randomized instruction set

emulation to disrupt binary code injection attacks
Elena Gabriela Barrantes et. Al.
10th ACM International Conference on Computer
and Communications Security (CCS)
Instruction Set Randomization

 Observation: attackers need to know the

instruction set

 Idea: Obfuscate the instruction set

How do we obfuscate?

 Encode the machine code of an

executable
 Decode instructions before sending to
processor
Encoding Process

• XOR a key with

instructions
• Worst case for attacker:
2^32 guesses

32-bit Key 32-bit Key 32-bit Key

⊕ ⊕ ⊕
Code

Barrantes et. al. Proposed a one time pad to the code

Decoding Process

 Decoding is performed when instructions are fetched

from memory
Encoding Key

Encoded
Instruction ⊕ Processor
Stream XOR
Practical Considerations

 Shared libraries
 Kc et al. implemented in hardware
(ideally)
 Barrantes et al. implemented in emulator
 Performance may suffer
 ISR Thwarts an Attack

0-day exploit
shellcode[] =
"\x31\xdb" // xorl Encoded:
"\x8d\x43\x17"// leal "\x31\xdb" // xorl
"\xcd\x80" // int "\x8d\x43\x17"// leal
... //... "\xcd\x80" // int
... //...
Decoded:
“\x23\x54” //invalid
“\xa3\x2f\x9e” //invalid
“\x65\xc1 //invalid

Attacker X86 Apache Web Server

ISR Protected

Crash!
ISR Conclusions

 The good: completely eliminates executing

injected code, seemingly

 The bad: do not always have to inject code

 Wheres the FEEB?
On the Effectiveness of
Instruction Set Randomization
N. Sovarel, D. Evans, and N. Paul
USENIX Security, 2005
On the Effectiveness of ISR

 ISR designed to prevent successful code

injection

 But, Sovarel et al. demonstrate attacks

that CAN inject code successfully
Assumptions

 Address of vulnerable buffer is known

 Same randomization key used for each
forked process
 Encoding vulnerable to known ciphertext-
plaintext attack
• XOR encoding satisfies this assumption
 X86 instruction set is used
Attack Methodology

Goal:
Distinguish between correct and
incorrect guesses
 Attack Methodology

Encoded Decoded:
Guess:
“\x23\x54” //invalid
\x01 //ret?
\x02 //ret? \xc5 //invalid (crash)
\x03 //ret? \xef //invalid (crash)
\x04 //ret? \x7a //invalid (crash)
\x05 //ret? \xc3 //valid
(observable behavior)

Attacker X86 Apache Web Server

ISR Protected
ISR Attacks

 Return attack

 Jump attack

 Extended attack
 Return Attack

 Inject a 1-byte near return instruction

 Incorrect guess causes a crash

 Correct guess causes observable behaviour
• For example, some output will be returned
Return Attack (2)

Top of stack Top of stack

… …
Local Buffer
Local Buffer Near return (0xc3)

… …
Return address Address of buffer
… Original return address
Bottom of stack Bottom of stack

Normal Stack Layout Stack Layout After Attack

Several Hurdles to Jump

 The stack has been corrupted

 What about false positives?

 False Positives

 Apparent correct behavior in several

circumstances:

• It was actually correct (1/256)

• Another opcode produced the same behavior;
'near return and pop' instruction (1/256)
• It decoded to a harmless opcode (NOP, etc),
and some other instruction produced the same
behavior
Reducing False Positives (2)

Use a harmless instruction to eliminate false positives

… …
Near return (0xc3) Harmless instr. (0x90)
(Previously guessed) Near return (0xc3)
… …
Address of buffer Address of buffer
… …
(1) Apparently correct (2) Double check
Reducing False Positives (3)

 Near return / near return and pop very similar

… …
Guessed ret instr. Guessed ret instr.
0x00 0xFF
0x00 0xFF
Address of buffer Address of buffer
… …

(1) Apparently Correct (2) Double Check

Return Attack Conclusions

 Strength: only need to guess a 1-byte

instruction at a time

 Weakness: stack corruption makes it

difficult to use reliably
Jump Attack
Jump Attack

 Inject a 2-byte short jump instruction

 Correct guess causes an infinite loop

 Incorrect guess causes crash
Jump Attack (2)

Top of stack Top of stack

… …
Local Buffer
Local Buffer Short jump (0xeb)
Offset (0xfe)
… …
Return address Address of buffer
… …
Bottom of stack Bottom of stack

Normal Stack Layout Stack Layout After Attack

False Positives

 Again, apparent correct behavior will be exhibited in

several circumstances:

• It was actually correct

• An incorrectly decoded instruction produced an
infinite loop; there are 16 near conditional jumps
• It decoded to a harmless instruction (NOP, etc), and
some other instruction produced an infinite loop
False Positives (2)
Change high bit in the 3rd byte to
eliminate false positives
… …
Short jump Short jump
Offset (0xfe) Offset (0xfe)
0x00 0xFF
Address of buffer Address of buffer
… …

(1) Apparently Correct (2) Double Check

Jump Attack Conclusions

 Strength:
• Use not restricted to special circumstances
 Weaknesses:
• 2-byte instruction must be guessed
• Infinite loops created
Extended Attack
Extended Attack

 Near jmp jumps to original return address

…
Short jump (0xeb)
offset
0xcd
…
0xcd
Near jump (0xe9)

{
offset
offset
Jump Attack
offset
offset
Address of buffer

Stack Layout After Attack

Extended Attack Conclusions

 Strengths:
• Not restricted to special circumstances
• Only creates a few infinite loops
 Weaknesses:
• Initially 2-byte instructions must be guessed
MicroVM

 Consider an ISR aware worm

 Proposed ‘MicroVM’ is only 100 bytes
long
• Use to execute small chunks of the worm at
a time
Results

• Is 6 minutes and 8,636 attempts reasonable?

Key Attempts Attempts Infinite Success Time (s)
Bytes per byte Loops Rate (%)
2 3983 1991.6 3.86 98 138.3
4 4208 1052.1 8.11 99 207.9
32 7240 226.3 8.28 98 283.6
100 8636 86.4 9.15 100 365.6
512 18904 36.9 8.31 95 627.4
1024 30035 29.3 7.90 100 947.3
4096 102389 25.0 8.36 95 2919.4
Practical Considerations

 The attacks make many assumptions

• Address of buffer is known
• Key is not re-randomized
• Encoding vulnerable to known plaintext-
ciphertext attack
 Attacks are x86 instruction set dependent
 Wheres the FEEB? Conclusions

 ISR can easily fix the assumptions

• In fact, Sovarel et. al. had to change the RISE
implementation to conform
 Take this paper as a lesson in safe
implementation
”if you’re going to implement ISR, make sure every
process gets a fresh key!”
“When I have tried to exploit buffer overflows, a
noop sled has always been needed”
ISR Conclusions
 The good – Effectively eliminates code
injection, if implemented correctly
 The bad – Implemented in hardware or
an emulator
 The ugly – Still, does nothing to protect
against return-to-libc
We still need a more general approach!
Address Space Randomization
Address Space Randomization

Observation: Attacker needs to know

certain addresses in memory

Idea: Obfuscate memory addresses

PaX ASLR

 PageEXec Address Space Layout

Randomization brought to us by the PaX
Team
 Popular open-source ASR implementation
• Hardened Debian
• Hardened Gentoo
• Grsecurity kernel enhancements
 Randomizes: stack, heap, libraries
PaX - Randomization

32-bit architecture process address space

delta_mmap

2^16 2^16 2^24

Image Source: http://www.csc.ncsu.edu/faculty/junxu/software/aslp/
On the Effectiveness of
Address-Space Randomization

Goal: Guess library offset and compute

location of system()

Means:
return-to-libc, lack of entropy in
PaX ASLR randomization
The Exploit

Note:

• Library offset is limited to 216 possibilities

• PaX ASLR does not rerandomize on fork()

• Relative addresses inside libraries are not

randomized
The Exploit - Setup

Apache web server on a 32-bit

architecture

PaX ASLR for randomization

Separated attack machine from victim

with a 100 Mbps network
The Exploit - Guessing Addresses

Send probes using return-to-libc attack

Unsuccessful guess crashes

Successful guess produces observable

behavior
TIME: usleep()
 Attack Methodology

Offset? Result:
0x00000001 Crash!
0x00000002 Crash!
0x00000003 Crash!
Sleep 16 seconds
0x00000004

Attacker X86 Apache Web Server

ASR Protected
Probing for the offset

Top of stack Top of stack

… …
… Arg (0x01010101)
Arguments Ret (0xDEADBEEF)
Return address Usleep() addr.
… AAAAAAAAAAAAAAAAA
64 byte buffer AAAAAAAAAAAAAAAAA
… …
Bottom of stack Bottom of stack

Normal Stack Layout Stack Layout After Attack

Return-to-libc Attack

Top of stack Top of stack

Buffer addr. Buffer addr.
… Ret (0xDEADBEEF)
… System() addr.
… Ret() addr.
Arguments Ret() addr.
Return address Ret() addr.
… AAAAAAAAAAAAAAAAA
64 byte buffer ‘/bin/sh’
… …
Bottom of stack Bottom of stack

Normal Stack Layout Stack Layout After Attack

ASR Conclusions

 The good: attempts to hinder all types of

memory exploits (defense-in-breadth)

 The bad: low entropy leaves it vulnerable

We can still do better!
A better approach to ASR?

 64-bit architecture
• Can increase randomness from 2^16 to 2^40
 Randomization Frequency
 Granularity
• Permute stack variables
• Permute code & library functions
• Permute static data
 Combine with other approaches
Questions?
References
Wheres the FEEB?
On the Effectiveness of
Instruction Set Randomization
N. Sovarel, D. Evans, and N. Paul
USENIX Security, 2005
References

On the Effectiveness of Address

Space Randomization
H. Schacham, M. Page, B. Pfaff, E.
Goh, N. Modadugu, D. Boneh
ACM CCS 04
References
Countering Code-Injection Attacks With
Instruction-Set Randomization
Gaurav S. Kc et. Al.
10th ACM International Conference on Computer
and Communications Security (CCS)

Intrusion detection: Randomized instruction set

emulation to disrupt binary code injection attacks
Elena Gabriela Barrantes et. Al.
10th ACM International Conference on Computer
and Communications Security (CCS)
References

 Thanks to Lucas Ballard for lending some of his

slides for this presentation.
 Images on slide 64 are from the Address Space
Layout Permutation project by Jun Xu at North
Carolina State Univ.