Code Injection Defense
CSC501 Operating Systems Principles
Outlineq Code-Injection Recapq Code-Injection Defense
Code-Injection Attacks
q Three essential stages1. Inject attack code2. Hijack control flow3. Execute attacker code
arg1arg1return addressreturn address
….….
bufbuf
prev. stack frameprev. stack frame
othersothers
......
Can be anythingCan be anything
Attack CodeAttack Code
Hijacked PC pointerHijacked PC pointer
Attack CodeAttack Code
Code Injection Defenseq StrategiesQ Detect and remove vulnerabilities (best)Q Detect and prevent code injectionQ Detect and prevent control flow hijackingQ Detect and prevent code execution
q Stages of interventionQ Analyzing and compiling codeQ Linking objects into executableQ Loading executable into memoryQ Running executable
Existing Approaches
q Security ExtensionsQ Non-Executable StackQ MemGuard, StackGuard, … Q Libsafe
q NX ProtectionQ Hardware vs. Software
q RandomizationQ Address Space Layout RandomizationQ Instruction Set Randomization
Non-Executable Stackq Basic stack exploit can be prevented by marking stack
segment as non-executable or randomizing stack location.Q Code patches exist for Linux and Solaris.
q Problems:Q Does not block more general overflow exploits:Ø Overflow on heap: overflow buffer next to func pointer.
Q Some apps need executable stack (e.g. LISP interpreters).
Code Injection Essential StepsAttack Code
InjectionControl Flow
HijackingAttack Code Execution
Non-Executable
Stack
Security Extensions -- MemGuard
q Main idea: prevent return address from changing via mark it as read-only.
q Extend VM model to protect user pages (such as return address in stack).
q Implementation detailsQ GCC’s function_prologue and function_epilogue
q Flaw: performance penaltiesQ Loading VM hardware is a privileged operation, and so the
application process must trap to kernel mode to protect a word.
Code Injection Essential StepsAttack Code
InjectionControl Flow
HijackingAttack Code Execution
MemGuard
Security Extensions -- StackGuard
q Main idea: the technique used to smash the stack currently always involve sequential memory writing.Q If the return address in stack was destroyed, the content
before the return address must be destroyed, too.
q Keep a “canary word” before return address and check this word before function returns
q Simple DemoQ http://nsfsecurity.pr.erau.edu/bom/StackGuard.html
The Canary
top of stack
bottom of stack
Process stack whilecalling a function
Return address
Canary word
Local variable
move canary-word into registerexclusive-or register with top-of-stackjump-if-not-zero to constant address .death-handleradd 4 to stack pointer<normal return instructions here>.death-handler
move canary-word into registerpush register
Function prologue: laying down a canary
Function epilogue: checking a canary
q If the attacker can easily guess the canary value, then the attack string can include the canary word in the correct place; therefore, the canary checking routine in function epilogue may become useless.Q Workaround?Ø randomize canary-word
Flaw in static canary
move canary-index-constant into registerpush canary-vector[register]
move canary-index-constant into registermove canary-vector[register] into registerexclusive-or register with top-of-stackjump-if-not-zero to constant address .death-handleradd 4 to stack pointer<normal return instructions here>.death-handler
Randomized Canary
Function prologue of randomized canary generator
Function epilogue of randomized canary checker
Code Injection Essential StepsAttack Code
InjectionControl Flow
HijackingAttack Code Execution
StackGuard
Security Extension -- Libsafeq Libsafe (Avaya Labs)Q Dynamically loaded library (LD_PRELOAD)Q Intercepts calls to strcpy (dest, src)Ø Validates sufficient space in current stack frame:
|frame-pointer – dest| > strlen(src)Ø If so, does strcpy.
Otherwise, terminates application.
destret-addrsfptopof
stacksrc buf ret-addrsfp
libsafe main
Code Injection Essential StepsAttack Code
InjectionControl Flow
HijackingAttack Code Execution
Libsafe
What are those unsafe functions
q strcpy()q strcat()q strtok()q sprintf()q vsprintf()q …
NX Protection (Hardware)
01101000100000100
01101000100110110
000100 110110000011 X000010 100101000001 X000000 X
000101 X000110 X000111 X001000 001011
Page Table
Page Frame
Physical Memory
Page Number Page Offset
RRWRWRRW
RRWRWRW
Protection
R X
R X
Question : Can we implement a software-based
NX protection?
TLB miss
Software-Based NX Protection
A
C
E
0
1
2
3
4
B
D
Logical Memory 9 V
i2 V
i5 V
01234
Page Table
Restart Process
Update PTE
Find Frame
A C
E
B
D
Get page from backing store
O.S.
Page fault
C
E
A
10
123
6789
54
0
Physical Memory
1 off
TLB
2
1
34
5
67
8
I-TLB
D-TLB
Bring in page
Instruction Fetch
Data Fetch
TLB miss
Software-Based NX Protection
A
C
E
0
1
2
3
4
B
D
Logical Memory
9 Vi
2 Vi
5 V
01234
Code Page Table
1 off
TLB
2
1
I-TLB
D-TLB
Instruction Fetch
Data Fetch
9 Vi
2 Vi
5 V
01234
Data Page Table
TLB miss
TLB miss
TLB miss
Software-Based NX Protection
A
C
E
0
1
2
3
4
B
D
Logical Memory
9 Vi
2 Vi
5 V
01234
Code Page Table
1 off
TLB
1
I-TLB
D-TLB
Instruction Fetch
Data Fetch
9 Vi
2 Vi
5 V
01234
Data Page Table
TLB miss
TLB miss
2
Restart Process
Update PTE
Find Frame
A
B
Get page from backing store
O.S.Page fault
C
E
A
10
123
6789
54
0
Physical Memory34
5
67
8Bring in page
Non-eXecuteNon-eXecute
Software-Based NX Protection
q Questions:Q Can we have two page tables for one process? Q How about CR3 – page directory base register?
q See work-around by PaXQ Exploiting segment support (SEGMEXEC)Q Overloading “supervisor bit” (PAGEEXEC)Ø http://www.answers.com/topic/pax-4
Code Injection Essential StepsAttack Code
InjectionControl Flow
HijackingAttack Code Execution
NX
Discussion on NX
q Prevents executing injected codeq Limitation:Q Exploit can still call system functions with arbitrary
argumentsØ e.g. system(“/bin/sh”)Ø Technique is called return-into-libc
Return-to-libc Attackq Overflows a buffer on stackQ e.g. local array variable
q Overwrites the return address with that of a library functionQ e.g. system(3)
q Also writes on stackQ False return address for library
function (RET2)Q Function arguments
RETEBP
buf[0..3]
RET2Arg
system()
" /bin/sh"
Code Injection Essential StepsAttack Code
injectionControl Flow
HijackingAttack Code Execution
Non-Executable
StackMemGuard
StackGuard
LibSafe
NX
Address Space Layout Randomization (ASLR)
q ASLR renders exploits which depend on predetermined memory addresses useless by randomizing the layout of the virtual memory address space.Q Base addresses of stack, heap, and code
segmentq When to do randomization:Q Compile- or link-time, or by rewriting existing
binaries
buff[128]
ARG1
LOCAL VARIABLESSAVED FRAME POINTER
RETURN ADDRESS
ARG2
Top of stack
WORM CODE
string buffer
375 bytes
String 1
42B0C9DC:
JMP ESP
ARG0
SQLSORT.DLL
Import
Address
Directory
LoadLibraryA()
GetProcAddress()
ESP = Stack Pointer Register
Example Shellcode from Windows Slammer worms
A Comparison
Code Injection Essential StepsAttack Code Injection Control Flow
HijackingAttack Code Execution
ASLR
Next Lectureq Protection – File System
Top Related