1 / 45

Chapter-4 Software Security

Chapter-4 Software Security. 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

morty
Download Presentation

Chapter-4 Software Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related