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