Defeating Security Attacks Through Runtime Mechanisms
description
Transcript of 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
• 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
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
• 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
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