View
242
Download
0
Category
Preview:
DESCRIPTION
Buffer Overflow Attack Stack Smashing Attack –Common mode of buffer overflow attack for hijacking system control Hijack Process Inject the attack code All applications are ready for injection Force the process to execute the injected code Stack buffer overflow vulnerability allow malicious input to overwrite the return address and to snatch the execution flow Text Area (program) Data Area Stack Area Malicious Code
Citation preview
A Survey onRuntime Smashed Stack
Detection 坂井研究室 M1 46424 豊島隆志
Background Vulnerability becomes Serious Social
Problems– ex)
Morris Worm on UNIX in 1988 Code Red on Windows in 2001 Nimda on Windows in 2001 Root DNS Attack in 2002
– CERT/CC Advisories
05
10152025303540
1988 1991 1994 1997 2000 2003
OthersBuffer overflow
Dominant Attacksare caused by
Buffer OverflowBuffer Overflow
Buffer Overflow Attack Stack Smashing Attack
– Common mode of buffer overflow attack for hijacking system control
Hijack Process1. Inject the attack code
All applications are ready for injection2. Force the process to execute the
injected code Stack buffer overflow vulnerability allow
malicious input to overwrite the return address and to snatch the execution flow
Text Area(program)
Data Area
Stack Area
Malicious Code
Stack Smashing Attack (1) Program Structure of C like languages
int main (int argc, char **argv){ … calc_something(x, y); … show_something(); … return 0;}
void calc (int n){ …}void calc_something (int x, int y)
{ … calc(x); …}
Stack Smashing Attack (2) Flow Control Data
int main (int argc, char **argv){ … calc_something(x, y); … return 0;}
void calc (int n){ …}void calc_something (int x, int y)
{ … calc(x); …}
First In Last Out Buffer
main: line n
calc_something: line m
Stack Smashing Attack (3) Local Variables
– Allocated in FILO bufferunified with flow control data
void calc (int n){ int a, b; char buffer[1024]; … foo(); bar();}
return address
char buffer[1024];
int b;
int a;
Local Variables
ofcalc()
Stack Frameof
calc()
Stack Smashing Attack (4) Injections and Hijacks
return address
char buffer[1024];
int b;int a;
malicious code
overwritten by buffer overflowas buffer[1024], …, buffer[1027]
0x046424
Malicious Code
0x046424
Approaches (1) Software Approaches
– Novel secure program languages or perfect programs without bugs
– Compiler approaches without fixing each source program
Static Analysis– A First Step Towards Automated Detection of Buffer Overrun
Vulnerabilities• “pointer” can not be analyzed perfectly
Runtime Detection– LibSafe (LibVerify) – wrapper library– StackGuard– StackShield– ProPolice
Approaches (2) Hardware Approaches
– Non-Exec Pages NonExecutable User Stack
– vs return-into-libc attack– signal handling
NonExecutable Data Pages– modified dynamic loader– modified just-in-time (JIT) compiler
– Secure Return Address Stack (SRAS) Architecture Support for Defending Against Buffer Overflow
Attacks A Processor Architecture Defense against Buffer Overflow
Attacks– Secure Cache
A Cache Architecture to Prevent Malicious Code Executions
Secure Return Address Stack (1)
Concept– Return-Address-Stack (RAS)
implemented at fetch or issue stage on modern processors– Pentium, Alpha, SPARC, POWER…
monitor the instructions which mean “call” and “return”– call: push current program counter to the RAS– return: pop an address from the RAS
for improvement of execution path prediction– but RAS is not perfectly matched with the real call
stack• speculative update with branch prediction• RAS table overflow
– Detect mismatches between RAS and Stack information raise exception
Secure Return Address Stack (2)
Improvement– Implement another RAS at commit stage
avoid speculative update– Table optimization
overflow handling– swap to/from main memory with hardware or OS
support enough size for the majority
– 64 entry• in the case of SPEC2000
050
100150200250300350400
bzip2craf
tyeon gapgccgzipmcfpars
erperl
bmktwolf
vortex
Maximum Function Call Depth
Secure Return Address Stack (3)
Non-FILO Control Flow Operation Problems– setjmp/longjmp Functions– C++ Exceptions– Multi Threading– Tail Recursion– (handmade eccentric assembly language programs!)
these are often historical and critical :-) Problem & Solution
– these codes access and modify the call stack directly cause mismatches between RAS and Stack information
– we can not treat these codes transparently with SRAS approach
special instruction sras_push and sras_pop are required for stack operation
Secure Cache (1) Concept
– Duplicate Cache-lines as read-only Replica-lines– Detect return address mismatches
between Cache-lines and Replica-lines
return address
Cache LineReplica Line
return address
malicious data
mismatch
Secure Cache (2) Advantages
– Efficient spaces without swap– Transparent support for Non-FILO Control Flow
Operations Disadvantage
– Detection is not perfect Lose replica information on cache line replacement
Commercial Implements NXBit / Execute Disable Bit
– AMD - Opteron / Athlon64– Intel - Itanium / Pentium4– Transmeta - Efficeon
SmartMIPS ASE– Secure Memory Spaces– Interpreted Language Acceleration– Cryptography Acceleration
SecureCore (ARM)– Memory Protection Unit– Jazelle Technology– Cryptography Acceleration
TrustZone (ARM)– programs marked as trusted run with high level privilege and
can access data in secure zone
Conclusion Stack Smashing Attacks is important security
problem Hardware approaches achieve more
transparent way– without modifications of applications
Realization of true transparent detection is difficult– Non-FILO Control Flow Operation Problems
setjmp/longjmp Functions C++ Exceptions Multi Threading Tail Recursion
– But … cool idea might realize sufficiently transparent detection
Recommended