15/6/2009 Prof. Hilfinger CS 164 Lecture 30A 1Language SecurityLecture 30A(from notes by G. Necula)5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 2Lecture Outline• Beyond compilers– Looking at other issues in programming languagedesign and tools• C– Arrays– Exploiting buffer overruns– Detecting buffer overruns5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 3Platitudes• Language design has influence on– Efficiency– Safety– Security5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 4C Design Principles• Small language• Maximum efficiency• Safety less important• Designed for the world as it was in 1972– Weak machines– Superhuman programmers (or so they thought)– Trusted networks5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 5Arrays in Cchar buffer[100];Declares and allocates an array of 100 chars100 *sizeof(char)0 12 995/6/2009 Prof. Hilfinger CS 164 Lecture 30A 6C Array Operationschar buf1[100], buf2[100];Write:buf1[0] = ‘a’;Read:return buf2[0];25/6/2009 Prof. Hilfinger CS 164 Lecture 30A 7What’s Wrong with this Picture?int i;for(i = 0; buf1[i] != ‘\0’; i++) { buf2[i] = buf1[i];}buf2[i] = ‘\0’;5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 8Indexing Out of BoundsThe following are all well-typed C and maygenerate no run-time errorschar buffer[100];buffer[-1] = ‘a’;buffer[100] = ‘a’;buffer[100000] = ‘a’;5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 9Why?• Why does C allow out-of-bounds arrayreferences?– Proving at compile-time that all array referencesare in bounds is impossible in most languages– Checking at run-time that all array references arein bounds is “expensive”• But it is even more expensive to skip the checks5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 10Code Generation for Arrays• The C code: buf1[i] = 1; /* buf1 has type int[] */C with bounds checksr1 = &buf1;r2 = load i;r3 = r2 * 4;if r3 < 0 then error;r5 = load limit of buf1;if r3 >= r5 then error;r4 = r1 + r3store r4, 1Regular Cr1 = &buf1;r2 = load i;r3 = r2 * 4;r4 = r1 + r3store r4, 1• The assembly code:Costly!Finding the array limits is non-trivial5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 11C vs. Java• C array reference typical case– Offset calculation– Memory operation (load or store)• Java array reference typical case– Offset calculation– Memory operation (load or store)– Array bounds check– Type compatibility check (for some arrays)5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 12Buffer Overruns• A buffer overrun writes past the end of anarray•Buffer usually refers to a C array of char– But can be any array• So who’s afraid of a buffer overrun?– Can cause a core dump– Can damage data structures– What else?35/6/2009 Prof. Hilfinger CS 164 Lecture 30A 13Stack SmashingBuffer overruns can alter the control flow ofyour program!char buffer[100]; /* stack allocated array */100 *sizeof(char)0 1299return address5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 14An Overrun Vulnerabilityvoid foo(char in[]) {char buffer[100];int i = 0;for(i = 0; in[i] != ‘\0’; i++){ buffer[i] = in[i]; }buffer[i] = ‘\0’;}5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 15An Interesting Ideachar in[104] = { ‘ ‘,…,’ ‘, magic 4 chars }foo(in); /* Return here: LRET */100 *sizeof(char)0 1299return addressfoo entry(LRET)100 *sizeof(char)0 1299return addressfoo exitmagic 4 chars5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 16Discussion• So we can make foo jump wherever we like.• Result of unanticipated interaction of twofeatures:– Unchecked array operations– Stack-allocated arrays and return addresses• Knowledge of frame layout allows prediction of wherearray and return address are stored– Note the “magic cast” from char’s to an address5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 17The Rest of the Story• Say that foo is part of a network server andthe in originates in a received message– Some remote user can make foo jump anywhere !• But where is a “useful” place to jump?– Idea: Jump to some code that gives you control ofthe host system (e.g. code that spawns a shell)• But where to put such code?– Idea: Put the code in the same buffer and jumpthere!5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 18The Plan• We’ll make the code jump to the followingcode:• In C: exec(“/bin/sh”);• In assembly (pretend): mov $a0, 15 ; load the syscall code for “exec” mov $a1, &Ldata ; load the command syscall ; make the system callLdata: .byte ‘/’,’b’,’i’,’n’,’/’,’s’,’h’,0 ; null-terminated• In machine code: 0x20, 0x42, 0x00, …45/6/2009 Prof. Hilfinger CS 164 Lecture 30A 19The Planchar in[104] = { 104 magic chars }foo(in);0 1299return addressfoo exit0x20, 0x42, 0x00, …• The last 4 bytes in “in” must be address of start of buffer• Its position might depend on many factors ! 5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 20Guess the Location of the Injected Code• Trial & error: gives you a ballpark• Then pad the injected code with NOP– E.g. add $0, $1, 0x2020• stores result in $0 which is hardwired to 0 anyway• Encoded as 0x202020200 1299return addressfoo exit0x20, …, 0x20, 0x20, 0x42, 0x00, …• Works even with an approximate address of buffer !The bad code5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 21More Problems• We do not know exactly where the return address is– Depends on how the compiler chose to allocate variables inthe stack frame• Solution: pad the buffer at the end with many copiesof the “magic return address X”0 1299returnaddressfoo exit0x20, …, 0x20, 0x20, 0x42, 0x00, …, X, X, X, X, …, X , X, …The bad code5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 22Even More Problems• The most common way to copy the bad code in astack buffer is using string functions: strcpy,strcat, etc.• This means that buf cannot contain 0x00 bytes– Why?• Solution:– Rewrite the code carefully– Instead of “addiu $4,$0,0x0015 (code 0x20400015)– Use “addiu $4,$0,0x1126; subiu $4, $4, 0x1111”5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 23The State of C Programming• Buffer overruns are common– Programmers must do their own bounds checking– Easy to forget or be off-by-one or more– Program still appears to work correctly• In C w.r.t. to buffer overruns– Easy to do the wrong thing– Hard to do the right thing5/6/2009 Prof. Hilfinger CS 164 Lecture 30A 24The State of
View Full Document
Unlocking...