Writing Secure Code: Software Flaws

1. Writing Secure Code:Software Flaws Based on: “19 Deadly Sins of Software Security – Programming Flaws and How to Fix Them”, Michael Howard, David LeBlanc and John Viega

2. Outline (1/3) • Memory Organization • Program Execution • Stack • Function Call

3. Outline (2/3) • Overflows • Stack Overrun • Heap Overrun • Format Strings • Integer Upper / Underflow • SQL Injection • Cross-Site Scripting – XSS

4. Outline(3/3) • Solutions • Validate input • Improper Error Handling • Summary • Buffer Overflow • Format String • Integer Overflow • SQL Injection • Cross-Site Scripting – XSS • Conclusion

5. Program Execution • Text Segment -> Program Code • Data Segment -> Static variables • Stack -> Functions, Dynamic variables • Heap -> Dynamic Memory Allocation

6. Stack Evolution Execute ‘printf’ Return of ‘printf’ void foo(char *str){ printf(str); } int main(){ printf(“\nMessage-1”); foo(“\nMessage-2”); } Start execution from ‘main’ Stack frame of printf() Execute ‘printf’ Return of ‘’printf Stack frame of printf() Stack frame of foo() Execute ‘foo’ Return of ‘foo’ Stack frame of main() Return of ‘main’

7. Stack • Last In First Out (LIFO) • Push (modify SP) • Pop (modify SP) • Top - Stack Pointer (SP) • Stack Frames • Frame Pointers (FP) (optional) • Local Base Pointer (LB) • Extended Base Pointer (EBP) – Reference to local variables (optional) • Stack Bottom – At fixed address

8. Stack Frame Parameters Return Address Calling Frame Pointer Local Variables SP+offset SP Addresses 00000000

9. Function Call • Prologue • Save state of the stack • Reserve required memory for the new function • Function Call • Push function’s parameters on the stack • Save Instruction Pointer (IP) • Function Return • Restore the organization of memory to the state immediately prior to calling the function

10. Function Call Sample Bottom of stack Top of memory 18 return address {addressof(y=3)} saved stack pointer y x buf Top of stack Bottom of memory x=2; foo(18); y=3; void foo(int j){ int x,y; char buf[100]; … }

11. Buffer Overflow • It is used since ’80 • 1988: Morris Worm • Buffer Overflowinsendmail • Become known at 1996 • Aleph One – Smashing the stack for fun and profit (Phrack)

12. Languages effected • C/C++ • Libraries written in C/C++ or Assembly • Older languages

13. Stack buffer overflow (1/6) • A buffer overflow is the result of stuffing more data into a buffer than it can handle • If the buffer is locating at the stack -> Stack Overflow • If the buffer is locating at the heap -> Heap Overflow

14. Stack buffer overflow (2/6) *s return address saved stack pointer buf void function (char *s){ char buf[8]; strcpy(buf,s); } void main(){ char large_string[256]; int i; for (i=0;i<255;i++) large_string[i]=‘A’; function(large_string); } • The function copies a supplied string without bounds checking by using strcpy() • If you run this program you will get a segmentation violation

15. Stack buffer overflow (3/6) …. • The first 8 chars from s are copied at the memory space allocated from buf • The rest 248 chars from s, overwrite the next 248 bytes in the stack • As a result the return address takes the value 0x41414141 (0x41 -> the hex representation of ‘A’), which is invalid for the program • Then the IP takes the value 0x41414141 • When the program tries to execute the next code instruction from IP, there occur a Segmentation Fault

16. Stack buffer overflow (4/6) • Buffer overrun attacks exploit a lack of bounds-checking on the size of input being stored in a buffer array • By writing data past the end of an allocated array, the malicious user can make arbitrary changes to the program state stored adjacent to the array

17. Stack buffer overflow (5/6) • Main Idea: Instead of an invalid address, use a valid address in the memory space of the process as the new return address of the function: • Return to another code instruction of the program • Or put shellcode in the overflowed buffer and return at the beginning of that code

18. Stack buffer overflow (6/6) • Execution of the main program • After the function call of process A • Put shellcode in local buffer B, overflow and overwrite the return address in order to return at the beginning of the shellcode

19. Redemption Steps • Replace dangerous String Handling Functions • strcpy -> strncpy, strlcpy (*nix), strcpy_s (CRT windows) • Audit Allocations • Check Loops and Array Accesses • Use Analysis Tools • Stack Protection • StackGuard (canary: terminator, random, or random XOR), Randomization, Stack Cookies • Use non-executable Stack and Heap • Solaris: non-executable stack patch

20. Examples (1/2) • Code Red Worm • http://en.wikipedia.org/wiki/Code_Red_worm • Pine • A remotely exploitable buffer overflow exists within the parsing of the message/external-body type attribute name/value pairs • http://www.derkeiler.com/Mailing-Lists/Securiteam/2003-09/0025.html • Winamp • The remote version of this software is vulnerable to a local buffer overrun when handling a large file name • http://shalb.com/kb/entry/16199/

21. Examples (2/2) • CVE-1999-0042 : “IMAP • CVE-2000-0389 : “Kerberos 4 and 5” • CVE-2000-0390 : “Kerberos 5” • CVE-2000-0391 : “Kerberos 5” • CVE-2000-0392 : “Kerberos 5” • CVE-2002-0842 : “Oracle9i Application Server 9.02” • CVE-2003-0095 : “Oracle Database Server 9i, 8i, 8.1.7, 8.0.6” • CVE-2003-0096 : “Oracle 9i Database Release 2, Release 1, 8i, 8.1.7, 8.0.6” • CAN-2003-0352 : “DCOM interface for RPC in Microsoft Windows NT 4.0, 2000, XP, Server 2003” • CA-2003-05 : “Multiple Vulnerabilities in Oracle Servers” • CA-2003-23 : “RPCSS Vulnerabilities in Microsoft Windows”

22. References • Smashing The Stack For Fun And Profit, by Aleph1 (Elias Levy) • www.insecure.org/stf/smashstack.txt • Writing secure Code, Second Edition, by Michael Howard and David C. LeBlanc • Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft windows Server 2003, by David Litchfield • www.ngssoftware.com/papers/defeating-w2k3-stack-protecion.pdf • The Tao of Windows Buffer Overflows, by Dildog • www.cultdeadcow.com/cDc_files/cDc-351/

23. Heap Buffer Overflow • Overflow a buffer that is located at heap • Similar to stack buffer overflow • But more difficult to exploit • Typically, it is used in order to change the access rights of the program

24. Heap buffer overflow attack • Variables such as • passwords • file names • uid • gid are putted on the heap • A malicious user, use heap overflow attacks to overwrite these variables and gain unauthorized access rights

25. Other problems • Many programmers don’t think that heap overrun attacks are executable • Stack protection mechanisms, like StackGuard, don’t protect heap • In some operating systems, there is a choice to make the stack non-executable, but there is no such a choice for the heap • By a successful heap overflow attack, the Stack protection mechanisms can be bypassed

26. History • The first heap overrun problem was detected at BSDI crontab in 1996 • A heap buffer was overflowed by coping a large file name • The exploit turn the variables uid and gid to zero and the attacker gain unauthorized access rights

27. Interesting Example (1/2) • Mnogosearch search engine written in C • Vulnerability in the URL decoding caused a heap overflow. • There was a number of variables in BSS space. One of which was used to send returned data to the client. Another of which was a pointer to memory used to hold variables passed in the url. Something like: void **variables = malloc(sizeof(void *) * variableindex); char Targ[8192];

28. Interesting Example (2/2) • Variables were inserted into ‘variables’ like so: variables[variable_index++] = strdup(data); • Using these two behaviours we could overwrite various addresses until we found the address of Targ (we know when we receive corrupted data back over the network) • Once we know the address of Targ we then know the address, relatively, of ‘variables’ • If we overwrite ‘variables’ with a rough guess of the GOT we then overwrite multiple GOT entries with addresses returned by strdup of our shellcode – 100% accurate!

29. Examples • Heap Overrun in HTR Chunked Encoding Could Enable Web Server Compromise • www.microsoft.com/technet/security/Bulletin/MS02-028.mspx

30. Buffer Overflow

31. Format Strings • One of the few truly new attack to surface in recent years • On of the first mentions was on June 23, 2000, by Lamagra Argamal • www.securityfocus.com/archive/1/66842

32. Languages effected • C/C++ • Libraries written in C/C++ or Assembly • Older languages

33. Description of Format Strings (1/3) int age = 20; printf(“Your age is %d\n”, age); This format string contains: • Text: “Your age is” • Format specifier for output of values: %d • Control characters: \n format string list of values

34. Description of Format Strings (2/3)Format String Specifiers

35. Description of Format Strings (3/3)Format String Specifiers

36. Format String Attack (1/8) Functions that take a variable number of arguments, have no way to know how many arguments are being passed in. printf(“Hello %s”, buf); (Correct call) printf(buf); (Probably Error) If variable buf contains a format string specifier, like %s, the function will try to read missing arguments from the stack and probably the program will crash

37. Format String Attack (2/8) What happens if the following code is run, assuming there always is an argument input by a user? int main (int argc, char *argv[]){ printf(argv[1]); exit(0);} Try it and input “%s%s%s%s%s%s%s%s%s”How many “%s” arguments do you need to crash it?

38. Format String Attack (3/8) printf( szUntrustedInputBuffer ); where szUntrustedInputBuffer takes the input data: ‘%d%d%d%d%n’ printf(szUntrustedInputBuffer); printf(‘%d%d%d%d%n’,1,2,3,4,n_var);

39. Format String Attack (4/8) • If we give the input • “%x %x” • There will be printed a result like ./a.out“%x %x” 12ffc0 4011e5 • Where the two values printed are the next 8 bytes in the stack

40. Format String Attack (5/8) • Usually, several ‘%x’ specifiers are used in order to reveal the data that are stored in the stack • ./a.out‘%x%x%x%x%x%x%x%x%x%x%x’ • This can give information to an attacker about the program, and simplifies his attacks • If secret or confident information is stored in the stack, it will be easily detected by a malicious user

41. Format String Attack (6/8) • Also the ‘%x’ specifier goes with ‘%n’ specifier in order to change the execution flow • Several ‘%x’ specifiers are used in order to cover the stack data until the return address and then a ‘%n’ specifier is used in order to overwrite the return address of the function • ./a.out‘%x%x%x%x%x%x%x%x%x%x%n’

42. Format String Attack (7/8) • Defined • Format string problems occur when a user has the ability to control or write completely the format string used to format data in the printf style family of C/C++ functions • Consequences • Confidentially: Format string problems allow for information disclosure which can severely simplify exploitation of the program • By using: %x • Access Control: Format string problems can result in the execution of arbitrary code • By using: %n, %x • Denial of Service: Several ‘%s’ specifiers make the process to read data from memory until an invalid memory address • By using: %s

43. Format String Attack (8/8) • Similarities with buffer overflows • Main goal is to overwrite the return address of the function in order to change the execution flow and execute arbitrary code • Differences with buffer overflows • A format string attack doesn’t need an overflowed buffer • A buffer overflow attack will overwrite all the stack data until the return address of the function • A format string attack can overwrite only the return address of the function without affecting the rest of the stack data • A successful format string attack can bypass the stack protection mechanisms, like StackGuard, as it won’t affect the canary bytes

44. Redemption Steps (1/2) • Never pass user input directly to a formatting function • fprintf(STDOUT, buf) • Ensure that all format string functions are passed a static string which cannot be controlled by the user and that the proper number of arguments are always sent to that function as well. If at all possible, do not use the %n operator in format strings

45. Redemption Steps (2/2) • Make sure that the format strings are only read from trusted places • Use specific paths • Check and limit the locale to valid values • In C++ use stream operators

46. Examples • CVE-2000-0573 : “wu-ftpd 2.6.0” • CVE-2000-0844 : “Functions that implement the locale subsystem on UNIX” • CVE-2008-0072 : “emf_multipart_encrypted function in mail/em-format.c in Evolution 2.12.3” • CVR-2008-5660 : “vinagre_utils_show_error() in src/vinagre-utils.c” • CA-2002-10 : “roc.rwalld” • CA-2002-12 : “ISC DHCPD” • CA-2001-27 : “CDE TollTalk”

47. References • Writing secure Code, Second Edition, by Michael Howard and David C. LeBlanc • Windows 2000 Format String Vulnerabilities, by David Litchfield • www.nextgenss.com/papers/win32format.doc • Format bugs, in addition to the wuftpd bug, by Lamagra Agramal • www.securityfocus.com/archive/1/66842 • Format String Attacks, by Tim Newsham • www.securityfocus.com/archive/1/81565

48. Format String

49. Integer Upper / Underflow • An integer overflow is an anomalous condition which may cause a buffer overflow, resulting in a computer security risk where adjacent, valid program control data may be overwritten, permitting the execution of arbitrary and potentially harmful code • An integer overflow, or integer wrapping, is a potential problem in program based upon the fact that the value that can be held in a numeric data type is limited by the data type’s size in bytes. ANSI C uses the following minimum sizes: • Data type size (bytes) • char 1 • short 2 • int 2 • long 4

50. Languages effected • All languages • C/C++ - most dangerous