CS5123 Software Validation and Quality Assurance

1. CS5123Software Validation and Quality Assurance Lecture 11 Common Bug Patterns-Security

2. Major Security Concerns Undermine usability DOS attacks Peculiar inputs causing crashes, bloats, … Information Leaking SQL Injection, Cross-site Scripting, unencrypted data, side channels, … Command and Control OS Injection, Cross-site Scripting, Return Oriented Programming, … 2

3. Vulnerabilities Avoid common vulnerabilities Buffer Overflow Injection Cross-Site Scripting 3

4. Buffer Overflow Quite many languages (C, C++) are memory unsafe You define a buffer, and it is your responsibility to keep your data in the buffer If you read or write to the place out of a buffer Semantic errors Crashes What else? Anything related to security? char buffer[12]; 4

5. Review of OS course: call stacks Function calls are traced by call stacks int main(int argc, char args**){ int result; if(argc >= 1){f(args[0]);} } void f(char* data){ char buffer[12]; strcpy(buffer, data) if(g()){return;} else{…} } bool g(){ ... } g f f f main main main main

6. Call stack of the function f The local variable buffer The parameter data The return address to go back to the call-site at main function char[12] buffer

7. Feed in a valid input Example “username” char[12] buffer

8. Feed in an invalid input Example “usernameusername” The parameter data is covered So it is no longer usable The return value is covered So can not return normally Still just a bug Minor security problem Undermines usability char[12] buffer

9. Feed in a malicious input Idea to do the trick Feed in an input with 20 chars Cover the return address f() will return to the code we Specify Consider the program is on a server, accessing user requests How to make it possible? Where to put the code? How to specify the return value to our code? char[12] buffer

10. Feed in a malicious input Use the buffer itself to store the code Set the return value to the buffer address Example Run exec(“/bin/sh”) to open a shell Translate to machine code char[12] buffer mov $a0 15 mov $a1 data syscall data: /, b, i, n, /, s, h 0x20, 0x42, 0x00, ...

11. Feed in a malicious input Other issues How to know the address of buffer[]: Programs are executed in virtual memory, so install the software and check memory state Buffer is too small to hold your code? Jump through return value to the stack frame of parent function char[12] buffer

12. The state of practice Buffer overflow is very common in C / C++ programs About 50% of new attacks are related to buffer overflow Known bugs are being exploited from time to time 12

13. How to deal with buffer overflow Boundary check for input-reachable buffers Not so easy in practice Check too many places: slow the software down Check too few places: buffer overflow risk Automatic supports Buffer Overflow Detection: libsafe, stackguard, … Runtime protection: weak memory safe Runtime protection: split stack 13

14. A real-world example If you are interested Here is a real world example: https://www.rcesecurity.com/2011/11/buffer-overflow-a-real-world-example/ 14

15. Injection Directly inject user input into code to be executed SQL Injection Inject code to SQL queries OS Injection Inject code to OS commands 15

16. SQL Injection An example A student information system You can query your grade for certain course, year, … You login to your session, and say you are going to search for the grade of “CS5123” What does the server do? 16

17. SQL Injection The malicious Input We want to inject code into the SQL query Say we want it to be “select * from Grade” It is the same with “select * from Grade where username = ‘you’ and course = ‘CS5123’ or ‘a’ = ‘a’” 17

18. OS Injection Quite Similar Consider a server is going to make a dir for you as a new user, and it will execute exec(“mkdir path/to/” + username) What username you should make up? An example: HahaGotyou | \bin\sh 18

19. Injection Protection Injection works by passing user inputs into back-end engines Can we simply cut off the path? Definitely NO We have to do some filtering We are going to work on the example: select * from Grade where username = ‘you’ and course = ‘CS4723’/**/or/**/‘a’=‘a’ 19

20. User Input Filtering What to filter? or ? => “oorr” can bypass it Space? => use /**/ can bypass it Quotes? A little bit difficult, we can search by year, and use year = 2009 or 1=1 Want more? See select * from Grade where username = ‘you’ and course = ‘CS4723’ or ‘a’ = ‘a’ http://websec.wordpress.com/2010/03/19/exploiting-hard-filtered-sql-injections/ 20

21. User Input Filtering: Other Issues Functioning of the software Filter ‘or’ will affect username ‘George’ Cannot filter space when space is allowed for the field Other string manipulations In web applications, there are HTML/URL escape characters &quot for “, &#39 for ‘, &nbsp / %20 for space, … Replacing escaping characters are common So &#39 may be used if quotes are disabled… Always be clear about how user inputs flows in your code 21

22. Cross Site Scripting One of the most popular attacks to web applications Everything is about where the input goes to This time it goes to a web page This becomes more popular with so-called web 2.0 (let users do the work, e.g., wiki, youtube, blogs) 22

23. XSS: Scenario 23

24. Example Bob wants to get all the login information of his friends in a social network So Bob writes a blog, in the blog, he writes: xxxxxxx, xxxx, <script>email(“bob@gmail.com”, getcookie())</script> Now Mary reads the blog, so the script runs, Bob will get the cookie, and will be able to login with Mary’s cookie… 24

25. Protection against XSS Limit the usage of cookies: may result in much inconvenience Quite similar to SQL Injection Try to filter dangerous things such as “<script>” from user’s input Also quite similar to SQL Injection There are a lot of ways to bypass the filtering, so always hard to do a correct filtering Even harder because HTML is more complex than SQL, and much more web page generations than database query points… 25

26. Core idea: Devil inputs Software Security is almost all about the malicious inputs Buffer Overflow, Injection, and XSS accounts for 70% to 80% of attacks each year… Also for DOS (Denial of Service) attacks An example: you may want to filter ‘\’ for security reasons, but if so, handling a input like ‘\\\....\\\\’ with n ‘\’s will take n2 CPU time… Consider all possible values of user inputs Never make assumptions to user inputs 26

27. Penetration Testing Random testing (or fuzzing) is often useful for security testing, because it can generate inputs that you cannot imagine Have security checks during the testing Buffer Overflow: whether any “out of boundary” happens Use boundary checker in testing, and disable them in distribution SQL Injection & XSS: whether user inputs reach syntax tree part of the HTML or SQL code Use taints during testing to track the user inputs along the execution 27