Defeating Security Attacks Through Runtime Mechanisms

Defeating Security Attacks Through Defeating Security Attacks Through Runtime MechanismsRuntime Mechanisms

Jun Xu

Center for Reliable and High-Performance Computing

Coordinated Science Lab. & Dept. of Computer Science

University of Illinois at Urbana-Champaign

http://www.crhc.uiuc.edu/DEPEND/

202/26/2003

Secure and Dependable ComputingSecure and Dependable Computing

• Experimental Analysis of Security and Dependability – Measurement-based study of operational data

• 200 machine-years Windows failure data from Microsoft• Security vulnerability data from CERT and SecurityFocus

– Test-bed for experimentation with security attacks and fault injections• Study of a broad spectrum of security attacks• Impact of errors on security –fault injection, SAN model (with S. Chen)

• Runtime software/hardware mechanisms for vulnerability masking– Two generic and complimentary software protection mechanisms

• Transparent Runtime Randomization• Control Data Randomization

– Architectural support for security • Reliability and Security Engine (with N. Nakka, Y. Perzov)• Secure Return Address Stack (SRAS)

302/26/2003

MotivationMotivation

• 60% of all CERT security advisories (1999-2002) – Programming bugs introduced

when implementing software

– Buffer overflow, format string, double free, integer overflow

• Observation:– Implementation bugs are fact of

life

– Customized solutions exist for some subclasses vulnerabilities

– Generic techniques needed for masking broad-range of vulnerabilities

buffer overflow format string

double free integer overflow

others

402/26/2003

OutlineOutline

• Introduction

• Transparent Runtime Randomization (TRR)

• Control Data Randomization (CDR)

• Architecture support for security– Reliability and Security Engine (RSE)– Secure Return Address Stack (SRAS)

• Conclusion and Future Work

502/26/2003

How Attacks Work?How Attacks Work?• Two conditions for a successful attack

– Injecting malicious code/data at address m in app. memory– Changing control data at address p to point to m

struct message { char buf[96]; int (*fptr)(char*);};struct message msg; int get_message(…){ msg.fptr = printf; gets(msg.buf); msg.fptr(msg.buf);}

m

p

msg.buf[96]

msg.fptr = printf

…

malicious code

malicious code

msg.fptr = m

m

602/26/2003

Characteristic of the AttacksCharacteristic of the Attacks• Key to a successful attack

– Correctly determine the runtime values of m or p

– An attacker’s approach

• Determine the type/version of the target OS and application

• Configure a pilot system, experiment with it

• Construct the malicious input

• Why runtime values of m or p can be determined?– Memory layout is fixed and addresses are highly predictable

– Lack of diversity in modern systems

• O.S. memory management is fixed

• Once compiled and deployed, a program’s memory layout remain fixed across its lifetime

• Uniformity becomes unnecessary burden

702/26/2003

Transparent Runtime RandomizationTransparent Runtime Randomization

• Introduce diversity into a system– Dynamically randomize the memory layout of a program

– Each invocation has a different layout

– Defeating attacks

• Breaks memory layout assumption

• Make it hard to determine m/p

• Implementation – transparent to application– Modify Linux kernel and dynamic program loader

– Memory regions that can be randomly placed

• Position independent regions: stack, heap, shared libraries

• Position dependent regions: global offset table (GOT)

802/26/2003

Position Independent RegionsPosition Independent Regions

• Different sections at different fixed locations

• Change the kernel routines– Part of the process

initialization modules

– Random offset is applied to different regions

use code

Kernel space

0xC0000000

0xFFFFFFFF

0x08048000

static data

bss

shared libraries0x40000000 ± Rand

0xBFFFFFFC - Randuser stack

user heap End_of_bss + Rand

902/26/2003

Position Dependent RegionPosition Dependent Region

Program code call plt_printf

PLTplt_printf: jmp *got_printf

GOTgot_printf: addr of printf()

code

data

heap

Program code call plt_printf

GOTgot_printf: addr of printf()

Relocated GOTnew_got_printf: addr of printf()

Changed PLTplt_printf:jmp *new_got_printf

1002/26/2003

Operations of TRR – An ExampleOperations of TRR – An Exampleuser type netscape

shell creates new process using fork load & init netscape

using execve() syscall

execve() syscall:1. maps executable to memory2. sets code/data segments3. TRR randomly places stack, heap, dynamic program loader4. transfers control to dynamic program loader

dynamic program loader

1. maps shared libs to memory2. TRR randomly relocates prog. GOT and rewrite PLT

netscape begins to execute

1102/26/2003

Performance EvaluationPerformance Evaluation• Program initialization overhead

– Kernel instrumentation: btw. execve and start of program execution– Measured in number of clock cycles, converting to micro-seconds– Overhead – 1% to 6%

• NO overhead once the program begins execution• Memory cost – extra copy of GOT – 200 Byte to 3.5 KB

Program Init. Time (usec) Program Description No TRD TRD Overhead

Memory Cost (bytes)

apache web server 1.98 2.07 4.88% 816 ghttpd web server 0.99 1.04 5.19% 248 nullhttpd web server 1.32 1.38 4.77% 296 wu-ftpd ftp server 1.77 1.79 1.16% 724 lpd printer server 1.79 1.82 1.74% 736 opensshd secure shell server 2.76 2.87 4.29% 1088 rpc.statd NFS stat server 0.99 1.05 6.14% 304 XFree86 X windows server 1.96 2.05 4.61% 928 cc1 GNU C compiler 0.99 1.04 5.08% 324 netscape web browser 8.66 8.89 2.71% 3668 pine Email client 6.80 6.93 1.90% 992 traceroute network diagnosis tool 0.99 1.04 4.27% 196 xemacs text editor 22.07 22.37 1.37% 2088

1202/26/2003

Summary – Transparent Runtime Summary – Transparent Runtime RandomizationRandomization

• Transparently introduce diversity into a system– Makes address values unpredictable

– Breaks the memory assumption by attackers

– Low overhead, transparent to applications

• Problem– Data segment cannot be randomized

1302/26/2003

OutlineOutline

• Introduction





1402/26/2003

How Attacks Work?How Attacks Work?• Two conditions for a successful attack

– Injecting malicious code/data at address m in app. memory– Changing control data at address p to point to m

struct message { char buf[96]; int (*fptr)(char*);};struct message msg; int get_message(…){ msg.fptr = printf; gets(msg.buf); msg.fptr(msg.buf);}

m

p

msg.buf[96]

msg.fptr = printf

…

malicious code

malicious code

msg.fptr = m

m

1502/26/2003

Control Data RandomizationControl Data Randomization• Control data

– Data used for control flow transfer – return address, function pointer– Control data are in writable memory, can be maliciously overwritten

• Control data randomization – detect malicious change– Encode control data when they are defined– Decode control data whenever they are used– Without knowing the key, cannot take control of a program– Decoding and use of un-encoded value causes crash – Randomization key is generated each time a program invoked

• Formally– a: addr. of data, v: real value of data, k : the encoding key– decode(k , encode(k , v)) = v– val(a) encode(k , v)– c_val (a) = decode(k , val(a)) = decode(k , encode(k , v)) = v– An attacker overwrites addr a using value v’ val(a) = v’

c_val(a) = decode(k , val(a)) = decode(k , v’) v

1602/26/2003

Example of Control Data RandomizationExample of Control Data Randomization

struct message { char buf[96]; int (*fptr)(char*);};struct message msg;

int get_message(…){ msg.fptr = printf; gets(msg.buf);

msg.fptr(msg.buf);}

struct message { char buf[96]; int (*fptr)(char*);};struct message msg;

int get_message(…){ msg.fptr = printf; msg.fptr = msg.fptr XOR KEY gets(msg.buf);

tmp_fptr = msg.fptr XOR KEY tmp_fptr(msg.buf);}

encoding

decoding

1702/26/2003

Function PointersFunction Pointers

• Not all cases of define/use should be randomized– May force an FP’s value into an unknown state

• Define of fp:– From symbolic function name: fp printf (encode)

• Implicit define: return printf, func(printf) …

– From value propagation: fp fp’

• Use of fp:– For control flow transfer: call *fp (decode)

– For explicit value propagation: fp’ fp

– For implicit propagation: return fp, func(fp) …

1802/26/2003

Function Pointer Define & Use ExampleFunction Pointer Define & Use Example

definition from symbol

Implicit definition from symbol

use – value propagation

use – control transfer

int (*global_fptr) () = main;

int main(){ static int (*static_fptr)() = main;

int (*auto_fptr)() = main;

global_ftpr = open; auto_fptr = main; return open; open(main) auto_fptr = global_fptr; open(global_fptr); return auto_fptr;

(*auto_fptr)();}

1902/26/2003

Initialized Function PointerInitialized Function Pointer• Function pointer initialization in declaration

– FP as Automatic variables• Initialization is done through compiler generated code• CDR generates extra code to encode FP at runtime

– FP as global/static variables • No code is generated by the compiler• The linker determines the value of FP, stores in the executable file.

• Global/static FP Initialization Handling– Not possible to encode at link time – key not available– CDR solution:

• Tag initialized global/static FP in parsing phase• Place the address of FP in a special read-only section in the object

file• Merge all such sections from object files into one section at link time• Generates special code in the executable to encode these FP when the

process is initialized

2002/26/2003

global/static variablepointer initialization

Function Pointer Initialization ExampleFunction Pointer Initialization Example

automatic FP init

int (*global_fptr) () = main;

int main(){ static int (*static_fptr)() = main;

int (*auto_fptr)() = main;

global_ftpr = open; auto_fptr = main; return open; open(main) auto_fptr = global_fptr;

(*auto_fptr)();}

2102/26/2003

CDR ImplementationCDR Implementation• Change the GNU C compiler gcc.

– At parsing phase, RTL phase, assembly generation phase, linking phase

– Code instrumentation done before optimization phase

• For function pointers – parsing phase– Determine if encoding/decoding needed

– Add extra nodes to intermediate tree for encoding and decoding

– Special handling initialized global/static FPs – parsing, assemble, linking

• For return addresses – RTL phase– Encode immediately after entering the function

– Decode immediately before returning

• Current encoding and decoding function: XOR

• Random key generated at process initialization time, stored a read-only location

2202/26/2003

Performance EvaluationPerformance Evaluation• SPEC 2000 Integer Benchmarks

– C Library is also compiled using the new compiler– Performance Overhead ranges from 1% to 5%– Most overhead is due to randomization of RA (return address)

0

100

200

300

400

500

600

700

800

164.

gzip

175.

vpr

176.

gcc

181.

mcf

186.

craf

ty

197.

pars

er

254.

gap

255.

vorte

x

256.

bzip

2

300.

twol

f

run

tim

e in

sec

on

ds

No CDRCDR for RACDR for FP & RA

2302/26/2003

Evaluation – EffectivenessEvaluation – Effectiveness• Experimental evaluation

– Security test-bed, real-world application, vulnerabilities and attacks– Representing different types of vulnerabilities

• Result– Local or remote shell – attack succeeds; Crash – attack fails – Crash is preferred to being hijacked

• Contributions – mask a broad range of vulnerabilities

Program Attack Type No Protection TRR CDR

traceroute double free local shell crash crash

sendmail integer overflow local shell crash crash

ghttpd stack smashing remote shell crash crash

rpc.statd format string remote shell crash crash

null httpd heap overflow remote shell crash crash

2402/26/2003

OutlineOutline

• Introduction





2502/26/2003

Reliability and Security Engine (RSE)Reliability and Security Engine (RSE)

Processor

Reliability & Security EngineReliability & Security Engine

Fetch Decode Execute MEM Write

checker 1 checker 2 checker n

instructionqueue

2602/26/2003

Protection Return Address – Safe CopyProtection Return Address – Safe Copy

• Current unified stack shares storage for:– Control information (return

address)

– Data: parameters, temporary variables, buffers

– When buffer is overrun, the return information is tampered

• A Safe Copy of Return Address– Save an extra copy for detection

return address 1

saved ebp

Local variables

f1()

return address 2

saved ebp

Local variables

f2()

return address 3

saved ebp

Local variables

f3()

2702/26/2003

Safe Copy of Return AddressSafe Copy of Return Address

return address 1

saved ebp

Local variables

return address 2

saved ebp

Local variables

return address 3

saved ebp

Local variables

return address 1

return address 2

return address 3

Memory Stack Safe Copy

Attack

return address 1

saved ebp

Local variables

return address 2

saved ebp

Local variables

return address 3

saved ebp

Local variables

return address 1

return address 2

return address 3

Memory Stack Safe Copy

MaliciousData & Code Safe

copy is immune!

2802/26/2003

Secure Return Address Stack (SRAS)Secure Return Address Stack (SRAS)

• Software Implementation– Changed the C Compiler, overhead up to 20%

• Exploiting existing hardware mechanism to reduce overhead

• Return Address Stack (RAS)– Implemented in fetch stage of modern processor

– Improve effective fetch bandwidth

– High prediction rate > 99%

– Redundant hardware copy of return addresses

• SRAS– Utilize the redundant hardware copy

– Hardware copy is immune from buffer overrun

– Detect return address tampering (stack smashing) when misprediction occurs

2902/26/2003

SRAS Design OptionsSRAS Design Options

• Speculative SRAS– Use the existing RAS, exception if misprediction

– Source of misprediction: speculative update, overflow, attack

• Non-speculative SRAS– An extra copy of RAS at commit stage

– Source of misprediction: overflow, attack

• Non-speculative SRAS with overflow handling– As Non-speculative SRAS

– Handles SRAS overflow

– Source of misprediction: attack

3002/26/2003

Non-Speculative SRAS with Overflow Non-Speculative SRAS with Overflow HandlingHandling

0%

1%

2%

3%

4%

5%

6%

7%

8%b

zip

2

cra

fty

eo

n

ga

p

gcc

gzi

p

mcf

pa

rse

r

pe

rlb

mk

two

lf

vort

ex

Performance Degradation for Different SRAS Size

Pe

rfo

rma

nc

e (

IPC

) D

eg

rad

ati

on

8

16

32

64

128

3102/26/2003

Summary and Future DirectionsSummary and Future Directions• Summary

– Transparent Runtime Randomization• breaking attacks by making address values unpredictable

– Control Data Randomization• breaking attacks by encoding/decoding control data

– Reliability & Security Engine, Secure Return Address Stack• A step toward architectural support for security

• Future Directions– Check-pointing and Recovery mechanisms for TRR and CDR– Large scale data analysis on causes of vulnerabilities

• Identify patterns and build checking tools– Continue the work on Reliability and Security Engine– Intrusion detection and tolerance in wired and wireless environment– Security and dependability for future ubiquitous wireless access network

• Experimentally study the underlying issues• Investigate trust-relationship and failure behavior in the hierarchy

Documents

Defeating Security Attacks Through Runtime Mechanisms