A Survey on Runtime Smashed Stack Detection

A Survey on
Runtime 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
Dominant Attacks
are caused by
Buffer Overflow
40
35
30
25
Others
Buffer overflow
20
15
10
5
0
1988 1991 1994 1997 2000 2003
Buffer Overflow Attack

Stack Smashing Attack
–

Common mode of buffer overflow attack for hijacking system control
Malicious Code
Hijack Process
1.
Inject the attack code

2.
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
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_something (int x, int y)
{
…
calc(x);
…
}
void calc (int n)
{
…
}
Stack Smashing Attack (2)

Flow Control Data
int main (int argc, char **argv)
{
…
calc_something(x, y);
…
return 0;
}
void calc_something (int x, int y)
{
…
calc(x);
…
}
void calc (int n)
{
…
}
First In Last Out Buffer
calc_something: line m
main: line n
Stack Smashing Attack (3)

Local Variables
– Allocated in FILO buffer
unified with flow control data
void calc (int n)
{
int a, b;
char buffer[1024];
…
foo();
bar();
}
int a;
Local Variables
of
calc()
int b;
char buffer[1024];
return address
Stack Frame
of
calc()
Stack Smashing Attack (4)

Injections and Hijacks
int a;
int b;
0x046424
char
buffer[1024];
Malicious
Code
0x046424
return
address
malicious code
overwritten by buffer overflow
as buffer[1024], …, buffer[1027]
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
Maximum Function Call Depth
•
in the case of SPEC2000
400
350
300
250
200
150
100
50
0
f r
i p 2 ft y o n a p c c z i p c s e m k o l f te x
b z c ra e g g g m p ar e rl b tw vo r
p
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
malicious data
return address
mismatch
return address
Replica
Cache Line
Line
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

Download Report