lec20-codeinjectiondefense · 2009. 4. 8. · code injection essential steps attack code injection...

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.




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

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




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




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


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


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


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

http://www.answers.com/topic/pax-4




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"


injectionControl Flow


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


ASLR

Next Lectureq Protection – File System

lec20-codeinjectiondefense · 2009. 4. 8. · code injection essential steps attack code injection...

Documents