1. CS5123 Software 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 3 Avoid common vulnerabilities Buffer Overflow
Injection
Cross-Site Scripting 3

4. Buffer Overflow 4 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: 14

15. Injection 15 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 16 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 17 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 18 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? 20
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’ 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, 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