Transcript System Security Overview

System Security Overview
Security is a Broad Area
• Prevent attacks
– Authentication and Access control
– Remove software bugs
– Signature generation and filtering
• Protect secrete
– Encryption (RSA, public-private key, ..)
• Detect attacks
– Intrusion detection
– Information flow tracking
• Diagnose attacks
– Vulnerability analysis
• Recovery from attacks
– Sandboxing
Motivation for Sandbox
• Often have to take applications from outside
sources and execute them locally:
– To trade stocks, you must download a JAVA applet
– To share files you must run a P2P client
– To view a file you must download and run the viewer
• Even programs coming for reputable sources
may have bugs or unintended side effects:
– Systems are too diverse, developer cannot possibly
know about all possible side effects
• End result, a great deal of code we run today is
deemed “unreliable”
Sandbox Goal
Limitations of Conventional OS protection
• Not enough isolation
– Programs can still see what other processes are running
on machines
– Can see the entire file system
– All programs running on the system have the same level
of access to the system call interface
• No fine-grain isolation
– Either programs are running on the system and have
access to all facilities that other programs have, or they
aren’t on the system at all
• OS’s can’t protect themselves very well
– Once you get root, you can install drivers, change
configurations, etc…You only need to compromise 1 root
process to do this.
UNIX chroot
bin
etc
usr
bin
[ROOT]
/
var
home
james
mike
etc
usr
chroot
var
home
tom
jerry
UNIX chroot
• chroot command
– chroot changes root directory
– Confines code to limited portion of file system
• Example use
– chdir /tmp/ghostview
– chroot /tmp/ghostview
– sutmpuser (or su nobody)
• Caution
– chroot changes root directory, but not current dir
– If forget chdir, program can escape from changed root
– If you forget to change UID (process is still root),
process could escape
Limitations with chroot/jail
Other Sandboxing Approaches
• Software Fault Isolation
– Modify binaries to catch memory errors
• Wrap/trap system calls
– Check interaction between application and
OS
Detecting Attacks
Background Check
• Trojans:
– Malicious programs disguised as legitimate ones
– Need to be executed by the user Do not propagate
• Viruses:
– Sections of code copied into other executable code
– Spread by infecting binaries passed between
computers
• Worms:
– Self propagating
– Complete programs, often quite complex
– These are the worst and most dangerous kind!
Virus vs. Worm
Intrusions
• Definition of an intrusion, some examples:
–
–
–
–
–
–
An outsider is able to gain access as a legitimate user
A legitimate user is able to gain more privileges
Information is leaked from a system
Resources on the system are used
A program on system is modified
Behavior of the system is modified
• Basically any event where access controls are
breached
Intrusion Detection
• Misuse Detection (Signatures)
–
–
–
–
A sequence of actions that violates a security policy
Can only detect “known” attacks
E.g. user modifies password file
Difficult to encode all instances of misuse
• Anomaly Detection
– Some statistical argument about events which are
abnormal
– E.g. user gives wrong password more than 3 times
– Can detect unknown attacks
Anomaly Detection
• Learning or Data Mining Approaches
– Gather a large amount of data
– Train statistical modeling algorithm on data
set
•
•
•
•
Bayesian Nets
Hidden Markov Models
Data Mining models
Others…
– Use the information on live or recorded events
to try and detect new attacks
Misuse Detection
An Example
Other Examples
• Buffer overflow detection:
– A setuid system does an exec call with certain
arguments
– A network packet has a lot of nop’s in it
– Extremely long arguments to string functions
• SYN flooding:
– Many, frequent SYN packets with no ACK’s following
• • Misuse triggers are usually very specific
– IDS may miss variants of known attacks
Generation of Attack Signatures
• Input signature generation
– Vigilante [SOSP’05]
– Bouncer [SOSP’07]
– Many others…
NIDS Limitations
• Limited visibility
– Can’t interpret encrypted traffic
– Can miss attacks if they don’t occur on the network
– Has trouble if placed at the gateway into a network of
heterogeneous hosts
• Records a lot of traffic
– Very difficult to be discriminating
• Usually end up recording everything
– Requires a fair amount of disk space and I/O
bandwidth
– May also require CPU time if there is a lot of traffic
and analysis is done in real time
Host-based IDS
• Tripwire:
–
–
–
–
Records MD5 checksums of critical files and binaries
Also checks file attributes, I.e. size, dates, permissions, etc…
Periodically verifies that the files have not been modified
Good for detecting root kits
• Root kit:
–
–
–
–
After breaking in, attacker wishes to hide her presence
Root kit is a set of Trojan binaries (ls, ps, netstat, etc…)
Hides files, processes belonging to attacker
May also include sniffers to gather username/passwords
Host-based IDS Limitation
• Need an IDS for every machine
• HIDS is accessible to the attacker once she
breaks in
– Usually part of the OS or an application
– Attacker can tamper with the IDS system
– If logs are on the system, attacker can “cook” them
• Always log IDS data on another, hopefully more secure
system!
• HIDS has view of one system
– Difficult to share data across systems
Challenges with IDS
• There exist over 100 Intrusion Detection
Systems
– Both open source and commercial
– Can be network based or host based or combination
• Main problem
– Too many false positives
– System administrators tend to ignore warnings after a
while
– Difficult to determine a good IDS policy
• Other problems
– Protecting the IDS itself against attack
Confidentiality
Sensitive Data is Everywhere
• Passwords, Credit Card numbers,
Medical Data, Military Data, Financial
Data, Cryptographic keys,etc.
• Handled by Databases, Web
Browsers, Mail Systems, etc.
The Fate of all this Data?
•
•
•
•
How long is a copy in memory?
How many copies are there?
Where were they copied to?
How did they get there?
Answer depends on many parts:
Operating System, Libraries, Compiler,
etc.
An Example
• Enter a password into your yahoo mail
login in Mozilla
• Where does it go?
– Kernel random number generator
– Kernel tty buffer
– Kernel socket buffer
– XFree86 event queue
– Mozilla strings on the heap
Data Can Live a Long Time
• In Memory
– Allocator and workload dependant
• On Disk
– Swap file, Core Dumps, Hibernation, VM
suspend
• On another machine
– Network mounted storage, core dump
shipping
Why is this a Problem
– Threats:
• Host or Application Compromise
• Accidental Leakage (Core shipping, leak to
lower privilege)
• Direct Physical Attack
– Increased risk of exposure
– Increases impact of compromise
Minimizing Data lifetime is Hard
1. Systems works against programmer
–
Zero out the contents:
•
•
•
•
–
Compilers may optimize it away
Program may unexpected halt before zeroing
Buffers in other components are out of programmers’
control
Interaction with features (logging, command history, etc)
Pin the memory:
•
•
OS Hibernation
VM suspending, migration
2. Programmers make mistakes
TaintBochs Usage Model
1. Record a sensitive workload in
Taintbochs (e.g. Enter a password into a
browser)
•
•
TaintBochs tracks sensitive data through memory
Log records complete history
2. Analyze results
Track Sensitive Data at the
Hardware Level
• Associate a “Tainted” bit with each byte
• Shadow Memory:
A = B in normal memory
Taint(A) = Taint(B) in shadow memory
• Taint at I/O interfaces
– Keyboard
– NIC
Taint Propagation
• Instrumented Instructions propagate taints
– Arithmetic instructions
– I/O instructions (in/out)
– Copy instructions
• Basic Policy: If an input is tainted, output is
tainted
Ex:
add $C,$A,$B # c = a + b
C is tainted if A or B is Tainted
Recording Taints as they Propagate
• Keep Running Log of
– Changes to memory
– Changes to Shadow memory
• Snapshot Registers as taints propagate
– $EIP = instruction that caused tainting
– $ESP = stack of offending instruction/function
Information Flow Tracking
• Can be used for
– Detecting confidential information leaking
– Detecting malicious hijacking (see LIFT
presentation)
Discussion
• Information flow ( or taint analysis) can be
implemented at
– Source code level
– Binary code level
• Tradeoffs?
Detecting Past and Present Intrusions
through Vulnerability-Specific
Predicates
Ashlesha Joshi, Samuel T. King,
George W. Dunlap, Peter M. Chen
(SOSP-2005)
Motivation
vulnerability
introduced
vulnerability
discovered
patch
released
patch
applied
• Red time interval: window of vulnerability during
which exploit is possible
• Prompt patching makes this interval smaller, but
cannot eliminate it
• What to do in what’s left of window of
vulnerability?
IntroVirt
• Use vulnerability-specific, perturbation-free
predicates to detect the triggering of a
vulnerability
– For “past” time interval, combine predicates with VM
replay
– For “present” time interval, combine predicates with a
response strategy
vulnerability
introduced
vulnerability
discovered
patch
released
patch
applied
Vulnerabilities-Specific Predicates
• Why vulnerabilities-specific?
1 char *str = some_string;
2 int len = strlen(str);
3 char buf[BUFSIZE];
4 strcpy(buf, str);
(len >= BUFSIZE)
Goals
• Predicates must not perturb the target state
• Predicates should be able to check
applications and OS
• Installing new predicates should not shut
down the target software
• Predicates should be easy to write
• Predicates should execute with low overhead
Where do Predicates Execute?
• Problems:
– Cannot perturb the target
state
– Both the application and
OS are vulnerable
• Run the target software inside a VM
• Run the predicates outside this VM
• Control VM execution:
– Register for events notification via function name or
source code line (software breakpoints)
Semantic Gap Between Predicates
and VM
• Problems:
– Gap between the abstraction predicate writers would
use and the abstraction exposed by VMM
– Examples:
• 1. strlen
= 3 (predicate writers),
(0x08040300) = 3 (VMM)
• 2. authentication, decryption, etc.
• Translate symbolic information to numeric
values using debug information
• Leverage Guest Functionality
Avoiding Perturbations to Target State
• Problems:
– Invoke existing code  modify the target state
– Cause the target to send out a message
– Cause the target to hang
• Checkpoint and Rollback
• Others
– Output supression
– Timeout on predicates execution
Preemptions between the
Predicate and the Bug
• Problem:
1
If (access(file, W_OK)) {
2
access(file, W_OK)
unlink(file);
3 }
• Predicate Refresh
– Re-check the predicates when the
target process is scheduled out/in
More Details: Difficulties for
Applications
• Process Creation and Termination
 complicate maintaining breakpoints
• Virtual page may not be mapped to a
physical page
 complicate maintaining breakpoints
 complicate application data access
Evaluation
• Revisit the goals
– Predicates must not perturb the target state
– Predicates should be able to check
applications and OS
– Installing new predicates should not shut
(< 500 microsec)
down the target software
?– Predicates should be easy to write
?– Predicates should execute with low overhead
An Example Predicate
Patch:
if ((addr + len) > TASK_SIZE) || (addr + len) < addr)
return –EINVAL;
Predicate:
#define TASK_SIZE 0xc0000000
void brkEventHandler() {
unsigned long addr = readVar(“addr”);
unsigned long len = readVar(“len”);
if ((addr + len) > TASK_SIZE) || (addr + len) < addr)
// use “alert” response strategy
cout << “brk bug triggerred” << endl;
}
Other Security-related Work
• Address randomization
– Randomize memory layout at every run to
prevent attacks
– Why?
• DieHard
• ReVirt: Back-tracking intrusions
Honeypots
• Honeypots are machines deliberately left
for attackers to compromise
– Used to gather information about attackers
– Lure attackers into revealing their presence to
protect real machines
Collapsar
Thank You!!!