Lecture 11
Program (in)security
Thierry Sans
15-349: Introduction to Computer and Network Security
The big picture
Information
System
Security
Identity
Policy
Provider
As Alice, can I access to ...?
Hypothesis
➢
Every user is authenticated
➢
Every access is checked (complete mediation)
➢
Every resource is accessed through programs
•
Everything is “fine” as long as long as the programs
behave as expected (trustworthiness)
What can go wrong?
➢
An “unknown” program might be executed
without the consent of the user
•
➢
Malicious program: virus, Trojan horse, keyloggers
How is that possible?
•
The user has been tricked
•
•
•
Cool pictures, email saying “I love you”
The program has been executed by a “well-known”
program
Lecture 4: Malicious programs
What can go wrong?
➢
A user might execute a “well-known” program
that does not behave as expected
•
Malicious code inside: Backdoors
•
Unsafe program that can have a wrong behavior
•
•
•
On “wrong” inputs
•
And/or with the wrong context of execution
The program has bugs
But how bugs can be a security issue?
What is the difference between safety and security?
Unexpected behaviors
➢
What happens when a bug occurs?
•
•
•
•
Nothing, the program or the OS are “fault tolerant”
The program gives a wrong result or crashes but
the security of the system is not compromised
The resources are no longer accessible (locked) or
the OS crashes
The program computes something that it is not
suppose to (malicious code)
Correctness vs. Security
➢
Correctness: satisfy specifications
•
➢
For reasonable inputs,
get reasonable output
Security: resist attacks
•
➢
[Mitchell]
For unreasonable inputs,
output not completely disastrous
Main difference
•
Active interference from the environment
Malicious inputs: Scenario 1
“cool song”
Alice's
Trusted Domain
Open with
Malicious inputs: Scenario 2
“normal inputs”
Alice's
Trusted Domain
running as
innocent
The program can be:
•
run as a service (daemon program)
•
run by the innocent user with the
owner privileges (unix's setuid)
Program (in)security
➢
➢
Program security flaws
•
Buffer Overflow
•
TOCTOU attacks
Web-specific program security flaws
•
Incomplete mediation
•
SQL Injections
Why buffer overflows are possible?
➢
Why an input (i.e. a data) can change the
program behaviors?
Because in Turing machines, the data and instructions are
the same thing: binary values in memory
Buffer overflow
➢
The idea
•
➢
When was it discover for the first time?
•
➢
Injecting a wrong data inputs in a way that it will be
interpreted as instructions
Understood as early as 1972
How bad is it nowadays?
•
Well, let's consult the US-CERT!
Stack buffers
➢
[Shmatikov]
Suppose Web server contains this function
void func(char *str) {
char buf[126];
strcpy(buf,str);
}
➢
Allocate local buffer
(126 bytes reserved on stack)
Copy argument into local buffer
When this function is invoked, a new frame with
local variables is pushed onto the stack
Stack grows this way
buf
Local variables
sfp
ret
addr
str
Frame of the Top of
calling function stack
Pointer to Execute Arguments
previous code at
frame this address
after func()
finishes
What if the buffer is overstuffed? [Shmatikov]
➢
Memory pointed to by str is copied onto stack…
void func(char *str) {
char buf[126];
strcpy(buf,str);
}
➢
strcpy does NOT check whether the string
at *str contains fewer than 126 characters
If a string longer than 126 bytes is copied into
buffer, it will overwrite adjacent stack
locations
buf
overflow
This will be
interpreted
as return address!
str
Frame of the Top of
calling function stack
Executing Attack Code
➢
[Shmatikov]
Suppose buffer contains attacker-created
string
• For example, *str contains a string received from
the network as input to some network service
daemon
Top of
Frame of the
code
Attacker puts actual assembly
instructions into his input string, e.g.,
binary code of execve(“/bin/sh”)
➢
ret
str
calling function
In the overflow, a pointer back
into the buffer appears in
the location where the system
expects to find return address
stack
When function exits, code in the buffer will be
executed, giving attacker a shell
• Root shell if the victim program is setuid root
Why are we still vulnerable to buffer overflows?
➢
Why code written in assembly code or C are
subject to buffer overflow attacks?
Because C has primitives to manipulate the memory
directly (pointers ect ...)
➢
If other programming languages are “memory
safe”, why are we not using them instead?
Because C and assembly code are used when a program
requires high performances (audio, vide, calculus ect ...)
or when it is dealing with hardware directly (OS,
compilers, drivers)
TOCTOU attacks
➢
➢
TOCTOU: Time Of Check to Time Of Use
(also called race condition attack)
Idea
•
➢
A file access is preliminary checked but when using
the file the content is different
What kind of program does it targets
•
•
Setuid's programs manipulating files
Concurrent programs (with different privileges)
that use files to share data
TOCTOU attacks in details
➢
A TOCTOU attack in 3 steps:
•
•
•
➢
1. The innocent user creates a file
2. The innocent users executes a setuid program
that will use this file
3. The (not so) innocent user changes the file to a
symbolic link pointing to a file that the user has not
the right to access
Condition to run this attack
•
The sequence of events requires precise timing
•
Possible for an attacker to arrange such conditions
The “printer” attack
ln -s innocent-file secret-file
Innocent's
trusted domain
Admin's
trusted domain
print
innocent-file
secret-file
print-program
running as Admin
Access Control
Printing
Web-based program security flaw
SQL-Injection
➢
Idea (looks like buffer overflow attacks)
•
Injecting SQL code in forms knowing that these
data will inserted in an actual SQL request
SQL password checking attack
Login: Alice
Password: whatever OR 1=1
SELECT uid WHERE user = Alice
AND password = whatever OR 1=1
Checkpwd( Alice, whatever OR 1=1)
Client's
trusted domain
Server's
trusted domain
Web-based program security flaw
Incomplete mediation
➢
Idea (looks like TOCTOU attacks)
•
The data are checked on the client side but they
are used on the server side. These data are
modified somewhere in between
The shopping cart attack
Item: Die­Hard 4 DVD
Quantity: 10
Generating the order but
no more checking on inputs
order(#2956,9,9.99,99.9
0.9
9 )
Client's
trusted domain
Here's your order,
thanks!
Total price is calculated by the client
(browser) according to a script in the page
Server's
trusted domain
Conclusion
➢
Tell me what is your conclusion?
What is coming next?
➢
How to mitigate or solve program security
issues?
•
➢
Lecture 3: Protection
What kind of malicious code would you want to
execute?
•
Lecture 4: Malicious code