1. Buffer overflow and stack smashing attacks Principles of application software security

2. Buffer overflows  One of the most common vulnerabilities in software  Particularly problematic when present in system libraries and other code that runs with high execution privileges.

3. How it works  Application reserves adjacent memory locations (buffer) to store arguments to a function, or variable values.  Attacker gives an argument too long to fit in the buffer.  The application copies the whole argument, overflowing the buffer and overwriting memory space.  If the conditions are “just right” this will enable to attacker to gain control over the program flow and execute arbitrary code, with the same privileges of the original application.

4. Stack smashing  Function (sub- routine) calls results in an activation frame being pushed onto a memory area called the stack. function arguments return address previous frame pointer local variables local buffer variables Direction of stack growth

5. Memory management  The stack, which contains activation frames, starts at the highest memory address allocated for the process, and grows downwards  Variable-length data (e.g., strings) that are read dynamically, are kept in the heap, which grows upwards  This arrangement maximizes flexibility of virtual memory management Stack Heap unitialized variables initialized variables code instructions Direction of stack growth Direction of heap growth

6. How to smash  Give application a very long string with malicious code  The string length, being much larger than the space allocated in the heap (buffer size declaration) causes the heap to overflow into the stack and overwrites the return address  The return address now points to the beginning of the malicious code function arguments Return address (overwritten with entry address of malicious code) Previous frame pointer (overwritten w/ malicious code) local variables (overwritten w/ malicious code) local buffer variables (overwritten w/ malicious code) Direction of stack growth

7. (a)Basic stack overflow C code (b) Basic stack overflow example runs Figure 10.5 Basic Stack Overflow Example $ cc -g -o buffer2 buffer2.c $./buffer2 Enter value for name: Bill and Lawrie Hello your name is Bill and Lawrie buffer2 done $./buffer2 Enter value for name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Segmentation fault (core dumped) $ perl -e 'print pack("H*", "414243444546474851525354555657586162636465666768 08fcffbf948304080a4e4e4e4e0a");' |./buffer2 Enter value for name: Hello your Re?pyy]uEA is ABCDEFGHQRSTUVWXabcdefguyu Enter value for Kyyu: Hello your Kyyu is NNNN Segmentation fault (core dumped) void hello(char *tag) { char inp[16]; printf("Enter value for %s: ", tag); gets(inp); printf("Hello your %s is %s\n", tag, inp); }

8. Memory Before After Contains Address gets(inp) gets(inp) Value of...... bffffbe0 3e850408 00850408 tag >....... bffffbdc f0830408 94830408 return addr.... bffffbd8 e8fbffbf e8ffffbf old base ptr.... bffffbd4 60840408 65666768 `... e f g h bffffbd0 30561540 61626364 0 V. @ a b c d bffffbcc 1b840408 55565758 inp[12-15].... U V W X bffffbc8 e8fbffbf 51525354 inp[8-11].... Q R S T bffffbc4 3cfcffbf 45464748 inp[4-7] <... E F G H bffffbc0 34fcffbf 41424344 inp[0-3] 4... A B C D...... Figure 10.6 Basic Stack Overflow Stack Values

9. Stack Overflo w Exampl e (a)Another stack overflow C code (b) Another stack overflow example runs Figure 10.7 Another Stack Overflow Example $ cc -o buffer3 buffer3.c $./buffer3 Input value: SAFE buffer3 getinp read SAFE read val: SAFE buffer3 done $./buffer3 Input value: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX buffer3 getinp read XXXXXXXXXXXXXXX read val: XXXXXXXXXXXXXXX buffer3 done Segmentation fault (core dumped) void getinp(char *inp, int siz) { puts("Input value: "); fgets(inp, siz, stdin); printf("buffer3 getinp read %s\n", inp); } void display(char *val) { char tmp[16]; sprintf(tmp, "read val: %s\n", val); puts(tmp); } int main(int argc, char *argv[]) { char buf[16]; getinp(buf, sizeof(buf)); display(buf); printf("buffer3 done\n"); }

10. Canary Guards  Like the legendary canary-in-the-mine, it detects stack smash attacks.  Inserts a “Canary value” just below the return address (Stack Guard) or just below the previous frame pointer (Stack Smashing Protector). This value gets checked right before a function returns.

11. SSP  Prevents overflow of local buffer variables  Canary value checking only takes place at return time, so other attacks possible function arguments return address previous frame pointer local buffer variables local non-buffer variables Direction of stack growth Canary value

12. Alternatives to canaries  Use a compiler that does full bounds checking, i.e., makes sure that the code always allocate enough memory for arguments  Significant performance penalty (Java/C)

13. Static analysis  Use a code analyzer to detect buffer overflows  Since checking that arbitrary code does not overflow is an undecidable problem, the code must be annotated in order for this to work  Depends on programmer expertise (costly)  Some common and useful programming techniques are prohibited (performance and engineering costs)  Advantage is that the compiled code does not suffer from performance deterioration

14. Safe libraries  Many vulnerabilities in code are due to unsafe use of system libraries  An alternative is to install a kernel patch that dynamically substitutes calls to unsafe library functions for safe versions of those  Not possible for closed-source systems such as MS operating systems

15. Memory address randomization  Patch at the kernel level, changing the memory mapping  Small performance penalty, by extra memory lookups (actually, extra cache lookups)  Makes it very difficult to perform a useful buffer overflow  However, unlike some other strategies, does not improve robustness (liveness) properties