Preventing Buffer Overflow Attacks.ppt

Some slides are in courtesy of J. Kurose and K. Ross Preventing Buffer Overflow Attacks Some unsafe C lib functions strcpy (char *dest, const char *src) strcat (char *dest, const char *src) gets (char *s) scanf ( const char *format, … ) printf (conts char *format, … ) Preventing buf overflow attacks Main problem: strcpy(), strcat(), sprintf() have no range checking. Use “safe” versions strncpy(), strncat() very carefully Defenses: Type safe languages (Java, ML). Legacy code? Mark stack as non-execute. Static source code analysis. Run time checking: StackGuard, Libsafe, SafeC, (Purify). Black box testing (e.g. eEye Retina, ISIC ). Marking stack as non-execute Basic stack exploit can be prevented by marking stack segment as non-executable Code patches exist for Linux and Solaris. Problems: Some apps need executable stack (e.g. LISP interpreters). Does not block more general overflow exploits: Overflow on heap: overflow buffer next to func pointer. Cannot make all the data segment non-executable More recent UNIX and MS windows emit dynamic code into program data for performance optimizations Static source code analysis Statically check source to detect buffer overflows. Several consulting companies. Several tools exist to automate the review process: Stanford: Engler, et al. Test trust inconsistency. @ (): SLINT (designed for UNIX) Berkeley: Wagner, et al. Test constraint violations. Find lots of bugs, but not all. Run time checking: StackGuard Many many run-time checking techniques … Solution: StackGuard (WireX) Run time tests for stack integrity. Enhance the code generator for emitting code to set up and tear down functions Embeds “canaries” in stack frames and verify their integrity prior to function return. Canary Types Random canary: (used in Visual Studio 2003) Choose random string at program startup. Insert canary string into every stack frame. Verify canary before returning from function. To corrupt random canary, attacker