A Survey on Runtime Smashed Stack Detection 坂井研究室 M 豊島隆志

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

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

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 buffer unified 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 of calc() Stack Frame of calc()

Stack Smashing Attack (4) Injections and Hijacks return address char buffer[1024]; int b; int a; malicious code overwritten by buffer overflow as buffer[1024], …, buffer[1027] 0x 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

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