Chapter-4 Software Security

1. Chapter-4Software Security

2. Why Software? • Why is software as important to security as crypto, access control and protocols? • Virtually all of information security is implemented in software • If your software is subject to attack, your security is broken • Regardless of strength of crypto, access control or protocols • Software is a poor foundation for security

3. Software Issues Attackers • Actively look for bugs and flaws • Like bad software… • …and try to make it misbehave • Attack systems thru bad software “Normal” users • Find bugs and flaws by accident • Hate bad software… • …but must learn to live with it • Must make bad software work

4. Complexity • “Complexity is the enemy of security” Lines of code (LOC) system

5. Software Security Topics • Program flaws (unintentional) • Buffer overflow • Incomplete mediation • Race conditions • Malicious software (intentional) • Viruses • Worms

6. Program Flaws • An error is a programming mistake • Done by human • An error may lead to incorrect state: fault • A fault is internal to the program • A fault may lead to a failure, where a system departs from its expected behavior • A failure is externally observable fault failure error

7. Example char array[10]; for(i = 0; i < 10; ++i) array[i] = `A`; array[10] = `B`; • This program has an error • This error might cause a fault • Incorrect internal state • If a fault occurs, it might lead to a failure • Program behaves incorrectly (external) • We use the term flaw for all of the above

8. Secure Software • In software engineering, try to insure that a program does what is intended • Secure software engineering requires that the software does what is intended… • …and nothing more • Absolutely secure software is impossible • Absolute security is almost never possible

9. Program Flaws • Program flaws are unintentional • But still create security risks • We’ll consider 3 types of flaws • Buffer overflow (smashing the stack) • Incomplete mediation • Race conditions • Many other flaws can occur • These are most common

10. Buffer Overflow • In computer security and programming, a buffer • overflow, or buffer overrun, is an anomaly where a • program, while writing data to a buffer, overruns the • buffer's boundary and overwrites adjacent memory. • This may result in abnormal program behavior, • including memory access errors, incorrect results, a • crash, or a breach of system security.

11. Buffer Overflow • Programming languages commonly associated with buffer overflows include C and C++, which provide no built-in protection against accessing or overwriting data in any part of memory and do not automatically check that data written to an array (the built-in buffer type) is within the boundaries of that array.

12. Buffer Overflow • Most commonly this occurs when copying strings of characters from one buffer to another.

13. Buffer Overflow • a program has defined two data items which are adjacent in memory: an 8-byte-long string buffer, A, and a two-byte integer, B. • Initially, A contains nothing but zero bytes, and B contains the number 1979. Characters are one byte wide.

14. Buffer Overflow • Now, the program attempts to store the null-terminated string ​"excessive"​ in the A buffer. By failing to check the length of the string, it overwrites the value of B: Although the programmer did not intend to change B at all, B's value has now been replaced by a number formed from part of the character string. That uses ASCII "e" followed by a zero byte would become the number 25856.

15. Exploitation • The techniques to exploit a buffer overflow vulnerability vary per architecture, operating system and memory region. For example, exploitation on the heap (used for dynamically allocated memory) is very different from on the call stack. • Stack-based exploitation • Heap-based exploitation

16. Buffer Overflow • Q: What happens when this is executed? • A: Depending on what resides in memory at location “buffer[20]” • Might overwrite user data or code • Might overwrite system data or code int main(){ int buffer[10]; buffer[20] = 37;}

17. Simple Buffer Overflow • Consider Boolean flag for authentication • Buffer overflow could overwrite flag allowing anyone to authenticate! Boolean flag buffer T F O U R S C … F • In some cases, attacker need not be so lucky as to have overflow overwrite flag

18. Memory Organization • low address • Text== code • Data== static variables • Heap== dynamic data • Stack== “scratch paper” • Dynamic local variables • Parameters to functions • Return address text data heap   • SP stack • high address

19. Stack-based exploitation • The malicious user may exploit stack-based buffer overflows to manipulate the program in one of the following method • By overwriting a local variable that is near the buffer in memory on the stack to change the behavior of the program which may benefit the attacker. • By overwriting the return address in a stack frame. Once the function returns, execution will resume at the return address as specified by the attacker. • By overwriting a function pointer

20. Heap-based exploitation • A buffer overflow occurring in the heap data area is referred to as a heap overflow and is exploitable in a different manner to that of stack-based overflows. • Memory on the heap is dynamically allocated by the application at run-time and typically contains program data. • Exploitation is performed by corrupting this data in specific ways to cause the application to overwrite internal structures such as linked list pointers.

21. Typical Attack Scenario • Users enter data into a Web form • Web form is sent to server • Server writes data to buffer, without checking length of input data • Data overflows from buffer • Sometimes, overflow can enable an attack • Web form attack could be carried out by anyone with an Internet connection

22. Simplified Stack Example low  void func(int a, int b){ char buffer[10]; } void main(){ func(1, 2); } : : • SP buffer • SP • return address ret a • SP b • SP high 

23. Smashing the Stack low  • What happens if buffer overflows? : : ??? • Program “returns” to wrong location • SP buffer • SP overflow ret • ret… NOT! • A crash is likely overflow a • SP b • SP high 

24. Smashing the Stack low  • Trudy has a better idea… : : • Code injection • Trudy can run code of her choosing! • SP evil code ret ret • SP a • SP b • SP high 

25. Smashing the Stack : : • Trudy may not know • Address of evil code • Location of ret on stack • Solutions • Precede evil code with NOP “landing pad” • Insert lots of new ret NOP : NOP evil code ret ret • ret : ret : :

26. Stack Smashing Summary • A buffer overflow must exist in the code • Not all buffer overflows are exploitable • If exploitable, attacker can inject code • Trial and error likely required • Stack smashing is “attack of the decade”

27. Example • Source code of the buffer overflow • Flaw easily found by attacker • Even without the source code!

28. Stack Smashing Example • Program asks for a serial number that the attacker does not know • Attacker does not have source code • Attacker does have the executable (exe) • Program quits on incorrect serial number

29. Example • By trial and error, attacker discovers an apparent buffer overflow • Note that 0x41 is “A” • Looks like ret overwritten by 2 bytes!

30. Example • Next, disassemble bo.exe to find • The goal is to exploit buffer overflow to jump to address 0x401034

31. Example • Find that 0x401034 is “@^P4” in ASCII

32. Example • Reverse the byte order to “4^P@” and… • Success! We’ve bypassed serial number check by exploiting a buffer overflow • Overwrote the return address on the stack

33. Stack Smashing Prevention • 1st choice: employ non-executable stack • “No execute” NX bit (if available) • Memory can be flagged so that the code can’t execute on specified location. • 2nd choice: use safe languages (Java, C#) • 3rd choice: use safer C functions • For unsafe functions, there are safer versions • For example, strncpy instead of strcpy

34. Incomplete mediation • Inputs to programs are often specified by untrusted users • Web-based applications are a common example • Users sometimes mistype data in web forms • Phone number: 51998884567 • Email: iang#cs.uwaterloo.ca • The web application needs to ensure that what the user has entered represents a meaningful request • This is called mediation

35. Incomplete mediation • Incomplete mediation occurs when the application accepts incorrect data from the user • Sometimes this is hard to avoid • Phone number: 519-886-4567 • This is a reasonable entry, that happens to be wrong • We focus on catching entries that are clearly wrong • Not well formed • DOB: 1980-04-31 • Unreasonable values • DOB: 1876-10-12 • Inconsistent with other entries

36. Why do we care? • What's the security issue here? • What happens if someone fills in: • DOB: 98764874236492483649247836489236492 • Buffer overflow? • DOB: '; DROP DATABASE clients -- • SQL injection? • We need to make sure that any user-supplied input falls within well-specified values, known to be safe

37. Client-side mediation • You've probably visited web site with forms that do client-side mediation • When you click “submit”, Javascript code will first run validation checks on the data you entered • If you enter invalid data, a popup will prevent you from submitting it • Related issue: client-side state • Many web sites rely on the client to keep state for them • They will put hidden fields in the form which are passed back to the server when the user submits the form

38. Client-side mediation • Problem: what if the user • Turns off Javascript? • Edits the form before submitting it? (Greasemonkey)‏ • Writes a script that interacts with the web server instead of using a web browser at all? • Connects to the server “manually”?(telnet server.com 80)‏ • Note that the user can send arbitrary (unmediated) values to the server this way • The user can also modify any client-side state

39. Example • At a bookstore website, the user orders a copy of the course text. The server replies with a form asking the address to ship to. This form has hidden fields storing the user's order • <input type=“hidden” name=“isbn” value=“0-13-239077-9”><input type=“hidden” name=“quantity” value=“1”><input type=“hidden” name=“unitprice” value=“111.00”> • What happens if the user changes the “unitprice” value to “50.00” before submitting the form?

40. Defences against incomplete mediation • Client-side mediation is an OK method to use in order to have a friendlier user interface, but is useless for security purposes. • You have to do server-side mediation, whether or not you also do client-side. • For values entered by the user: • Always do very careful checks on the values of all fields • For state stored by the client: • Make sure the client has not modified the data in any way

41. TOCTTOU errors / Race Condition • TOCTTOU (“TOCK-too”) errors • Time-Of-Check To Time-Of-Use • Also known as “race condition” errors • These errors occur when the following happens: • User requests the system to perform an action • The system verifies the user is allowed to perform the action • The system performs the action

42. Race Condition • Security processes should be atomic • Occur “all at once” • Race conditions can arise when security-critical process occurs in stages • Attacker makes change between stages • Often, between stage that gives authorization, but before stage that transfers ownership • Example: Unix mkdir

43. mkdir Race Condition • mkdir creates new directory • How mkdir is supposed to work mkdir 1. Allocate space 2. Transfer ownership

44. mkdir Attack • The mkdirrace condition mkdir 1. Allocate space 3. Transfer ownership 2. Create link to password file • Not really a “race” • But attacker’s timing is critical

45. Race Conditions • Race conditions are common • Race conditions may be more common than buffer overflows • But race conditions harder to exploit • To prevent race conditions, make security-critical processes atomic • Occur all at once, not in stages