Lecture 11
Program (in)security
Thierry Sans
15-349: Introduction to Computer and Network
Security
The big picture
Information
System
Security
Policy
As Alice, can I access to ...?
Identity
Provider
Hypothesis
➢
Every user is authenticated
➢
Every access is checked (complete mediation)
➢
Every resource is accessed through programs
•
Everything is “fne” 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 “wellknown” 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 specifcations
•
➢
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 (more severe)
“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)
Reminder
➢
Difference between
•
Threat
•
Vulnerability
•
Exploit
•
Counter-measure
How to know the vulnerabilities?
➢
How do you know about a vulnerability?
•
You fnd a bug yourself and investigate
•
You start becoming a hacker
•
You know where to fnd them
•
Let's consult the US-CERT!
Timeline of a vulnerability
A program is released with
a security vulnerability
The vulnerability is
publicly disclosed
A patch
is released
The patch
is applied
People say that “blah blah” is more vulnerable
➢
Consider that some programs are
•
more deployed than others
•
so more targetted by hackers
•
more complex than others
•
so more multiple points of failure
•
more open to third-party code than others
•
so more “amateur” codes
How to compare OS and programs?
➢
The number of vulnerabilities?
WRONG IDEA
Source: Secunia “Half-year report 2010”
What Makes A Good Security Metric?
[Johnathan Nightingale]
➢
Severity
•
Some bugs are directly exploitable
others requires the user to “cooperate”
➢
Exposure Window
•
➢
How long the users is exposed to the vulnerability
Complete Disclosure
•
Do vendors always disclose vulnerabilities when
found internally?
Program (in)security
➢
Main program security faws
•
Buffer Overfow
•
TOCTOU attacks
Why buffer overfows 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 overfow
➢
The idea
•
➢
Injecting a wrong data inputs in a way that it will
be interpreted as instructions
When was it discover for the frst time?
•
Understood as early as 1972
Stack buffers
➢
[Shmatikov]
Suppose a web server contains this function
void func(char *str) {
Allocate local buffer
(126 bytes reserved on stack)‫‏‬
char buf[126];
strcpy(buf,str);
}
➢
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
Pointer to Execute
Arguments
previous
code at
frame this address
after func()‫‏‬
finishes
Frame of the
calling function
Top of
stack
What if the buffer is overstuffed? [Shmatikov]
➢
Memory pointed to by str is copied onto
stack…
strcpy does NOT check whether the string
at *str contains fewer than 126 characters
void func(char *str) {
char buf[126];
strcpy(buf,str);
}
➢
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
calling function
Top of
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
code
Attacker puts actual assembly
instructions into his input string, e.g.,
binary code of execve(“/bin/sh”)‫‏‬
➢
ret
str
Frame of the
calling function
Top of
stack
In the overflow, a pointer back
into the buffer appears in
the location where the system
expects to find return address
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 overfows?
➢
Why code written in assembly code or C are
subject to buffer overfow 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)
Exploiting a buffer overfow attack
➢
Find the buffer overfow bug
➢
Study it
➢
Inject the shell code
➢
Use the attack
TOCTOU attacks
➢
➢
TOCTOU: Time Of Check to Time Of Use
(also called race condition attack)
Idea
•
➢
A fle access is preliminary checked but when
using the fle the content is different
What kind of program does it targets
•
•
Setuid's programs manipulating fles
Concurrent programs (with different privileges)
that use fles to share data
TOCTOU attacks in details
➢
A TOCTOU attack in 3 steps:
•
•
•
➢
1. The innocent user creates a fle
2. The innocent users executes a setuid program
that will use this fle
3. The (not so) innocent user changes the fle to
a symbolic link pointing to a fle 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 (race condition)
The “printer” attack
ln -s innocent-file secret-file
Innocent's
trusted domain
Admin's
trusted domain
print
innocent-fle
secret-fle
print-program
running as Admin
Access Control
Printing
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
Web-based program security faw SQL-Injection
➢
Idea (looks like buffer overfow 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 faw
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
modifed somewhere in between
The shopping cart attack
Item: Die-Hard 4 DVD
Quantity: 10
0.9
order(#2956,9,9.99,99.9
Generating the order but
no more checking on
inputs
)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