Trustworthy Systems

TRUST 2nd Year Site Visit, March 19th, 2007

Trustworthy Systems

Group Leaders:

Alex Aiken

Mike Reiter

David Wagner

Trustworthy Systems 2TRUST 2nd Year Site Visit, March 19th, 2007

Scope

Includes at least Trustworthiness via software analysis Trustworthiness via hardware assist Trustworthiness by distribution

More generally, this area has become the home for topics that don’t fit in the other areas

The primary “home” for secure systems and software research in TRUST


Trustworthiness via Software Analysis


Spotlights

EXecution generated Executions– Dawson Engler (Stanford)

Joe-E: A language for security– David Wagner (UC Berkeley)

Static analysis for security– Alex Aiken (Stanford) and David Wagner (UC

Berkeley)


Generic features: – Baroque interfaces, tricky input, rats nest of

conditionals.– Enormous undertaking to hit with manual testing.

Random “fuzz” testing– Charm: no manual work– Blind generation makes hard

to hit errors for narrow input range

– Also hard to hit errors that require structure

Next: a simple trick to finesse.

EXE:

Goal: find bugs in systems code

int bad_abs(int x) { if(x < 0)

return –x; if(x == 12345678) return –x; return x;}


Basic idea: use code itself to construct its input! Basic algorithm:

– Symbolic execution + constraint solving.

– Run code on symbolic input, initial value = “anything”– As code observes input, it tells us values input can be.– At conditionals that use symbolic input, fork

On true branch, add constraint that input satisfies check On false that it does not.

– exit() or error: solve constraints for input.– Rerun on uninstrumented code = No false positives.– IF complete, accurate, solvable constraints = all paths!

EXE:

EXecution generated Executions


– Initial state: x unconstrained

– Code will return 3 times.

– Solve constraints at each return = 3 test cases.

EXE:

The toy example

int bad_abs(int x) { if(x < 0)

return –x; if(x == 12345678) return –x; return x;}

int bad_abs_exe(int x) { if(fork() == child) constrain(x < 0); return -x; else constrain(x >= 0);

if(fork() == child) constrain(x == 12345678); return -x; else constrain(x != 12345678); return x;}


EXE:

The mechanics

User marks input to treat symbolically using:

Compile with EXE compiler. Uses CIL to– Insert checks around every expression: if operands all

concrete, run as normal. Else, add as constraint– Insert fork calls when symbolic could cause multiple acts

./a.out: forks at each decision point.– When path terminates use STP to solve constraints.– Terminates upon exit, crash, or EXE detects err

Rerun concrete through uninstrumented code.


EXE:

Trend: mount untrusted disks

Removable device (USB stick, CD, DVD) Let untrusted user mount files as disk images


EXE:Automatically generating malicious disks

File systems:– Mount untrusted data as file systems (CD-rom, USB)– Let untrusted users mount files as file systems.

Problem: bad people.– Must check disk as aggressively as networking code.– More complex.– FS guys are not paranoid.– Hard to random test: 40 if-statements of checking.– Result: easy exploits.

Basic idea: – make disk symbolic, jam up through kernel– Cool: automatically make disk image to blow up kernel!


EXE:

A galactic view

EXE-cc instrumented

1

2

3

4 5

Unmodified Linux

ext3

User-Mode-Linux


EXE:

Results

Checked ext2, ext3, and JFS mounts

Ext2: four bugs.– One buffer overflow read and write arbitrary

kernel memory (next slide)– Two div/mod by 0– One kernel crash

Ext3: four bugs (copied from ext2) JFS: one NULL pointer dereference

Extremely easy-to-diagnose: just mount!


EXE:

Generated disk of death

Create 64K file, set 64th sector to above. Mount.

And PANIC your kernel!

(JFS, Linux 2.4.19, 2.4.27, 2.6.10)


EXE:

Simplified: ext2 r/w kernel memory

int ext2_overflow(int block, unsigned count) { if(block < lower_bound

|| (block+count) > higher_bound)return -1;

while(count--)bar(block++);

}void bar(int block) { // B = power of 2 int block_group = (block-A)/B; … //array length is 8 … = array[block_group] … array[block_group] = … …}

block is symbolicblock + count can overflow and becomes negative!

block_group is symbolicblock can be large!Symbolic read off bound

Symbolic write off bound

Pass block to bar


EXE:

Conclusion [Oakland’06, CCS’06]

Automatic all-path execution, all-value checking– Make input symbolic. Run code. If operation

concrete, do it. If symbolic, track constraints. Generate concrete solution at end (or on way), feed back to code.

– Finds bugs in real code. Zero false positives.– But, still very early in research cycle.

Current work:– Checking networking code (“packets of death”)– Device drivers.

– Some results: one CERT advisory in PCRE, DHCPD bugs, BPF exploits.


Joe-E:

A Language for Security

Problem: Current systems fail to follow the principle of least privilege– This contributes to the virus and worm problem

Joe-E: a new programming language designed to support least privilege and privilege separation– Designed as a subset of Java, to ease adoption

Tech transfer: Joe-E is being used by HP Labs to build Waterken, an extensible web server (12K SLOC)


Joe-E:

The approach

All variables haveglobal scope

Global variablesconsidered harmful

Languages withlexical scoping

(poor practice) (better practice) (language support)

All privilegesglobally accessible

Privilege separation:privs are module-local

Joe-E: global scopeprovides no privilege


State of the art

• Research direction: Reason about software security properties, using program analysis & type inference• Goal: Reduce occurrence, impact of security bugs

Security via Static Analysis:

Goals

Best-effortbugfinding

Soundness

manual audits,grep

Verify absenceof classes of bugs full program

verification



Example: User/Kernel Bugs

OS kernel and user share the same address space

Kernel must take care with user-created pointers– Kernel may corrupt memory by inadvertent dereference of

malicious user-created pointer

kernel

user

user

unmapped

4GB

3GB

0

kernel

user

unmapped

4GB

3GB

0



A User/Kernel Security Hole

•Attack: what if p points into kernel memory?• Attacker can read secrets from kernel buffers• Attacker can gain root privileges e.g., by overwriting his own euid with all zeros

int x;void sys_setint(int *p) { memcpy(&x, p, sizeof(x)); }void sys_getint(int *p) { memcpy(p, &x, sizeof(x)); }

Kernel code



History

Johnson & Wagner, 2004– Type-inference based approach for Linux– Discovered a number of user/kernel bugs– Scaled to 300,000 LOC

Dor, Das, et al, 2004– Path-sensitive dataflow analysis for Windows– Scaled to 1M LOC

Sparse– Unsound, intraprocedural type-qualifer checker for Linux– Requires annotations on many (most?) functions– As of 2006, kernel is extensively annotated



Research Issues

Operating Systems are hard to analyze– Big: Linux has 6MLOC– Complex: High density of tricky code

Approach– For each program point– For each pointer p– Compute a boolean condition under which p is a

checked/unchecked user pointer– Use SAT to test satisfiability of conditions– An extreme in path sensitive analysis



Current Results

Analyze all of Linux

Currently gives 450 warnings on all of Linux– Most of these could be eliminated with more work– Less than 1 warning/10,000 LOC

Analysis derives sound aliasing information

But assumes memory safety– E.g., no buffer overflows– A separate problem to check . . .


Trustworthiness via Hardware Assist


Spotlight

Nexus operating system for trustworthy computing– Emin Gün Sirer, Fred B. Schneider (Cornell)


Nexus:

Motivation

New hardware for trustworthy computing is here

TPMs enable a new and novel set of applications– Applications that can provide guarantees about their run time

behavior

Current operating systems are ill-equipped to take advantage of this hardware


Nexus:

TPM Features

Hold secrets– Data Integrity Registers (DIRs) can hold arbitrary data in

persistent storage

Create keys– A master private key (EK) embedded on chip can vouch for

integrity of subsequently generated keys

Issue statements– Platform Configuration Registers (PCRs) can securely encode

state of the current computation


Nexus:

Problems (1/3)

Traditional OS in the certificate chain makes statement meaningless– Windows/Linux provide many interfaces by which

process state can be modified– A bug in any device driver can render statements

inoperative

Need smaller TCB– Support principle of least privilege– Provide strong isolation


Nexus:

Problems (2/3)

Traditional attestation captures system snapshot via hashes taken at boot-time– Hashes capture both too much and too little– Any change in program binary will lead to a different

hash, regardless of semantics– Can only capture properties that can be extracted at

boot-time

Need OS mechanisms to reason about program executions, not representations.


Nexus:

Problems (3/3)

TPM has limited resources– Only 2 DIRs, 16 PCRs, 16 keys– The raw TPM interface is unsafe to expose to

applications

Need OS abstractions that hide TPM details from applications


Nexus:

A New OS

– Based on a small TCB achieved through a componentized architecture.

Export component (event generator) Introduce reference monitor (event checker)

– Provides new OS mechanisms for attesting to dynamic program properties based on:

Provenance Analysis Rewriting

– Provides new OS abstractions for generalizing and virtualizing the TPM


Nexus:

Organization


Trustworthiness by Distribution


Two Spotlights

Nightwatch: An auditing framework forlarge scale distributed systems– Robbert van Renesse (Cornell)

Deployment of intrusion-tolerant services in a WAN– Mike Reiter (Carnegie Mellon)


Nightwatch:

Motivation

Distributed systems are complex Unexpected failures may occur

– Software bugs– Network failures– Unpredicted load– Improper tuning– Rational or malicious behavior


Nightwatch:

Hybrid auditing model

Queries/Updates

Audited System

+ Local

Auditors

Global Auditors

Local Auditor

System App

Hybrid global + local auditors scheme Probabilistic querying Internal fault tolerance Adaptivity to current conditions


Nightwatch:

Roles

Local Auditors– Query the component executing at their host node

and exchange information with neighboring local auditors and with global auditors

Global Auditors– Monitor local auditors and are responsible for

decisions on whether or not to react to violations– Collect sample statistics and identify global

parameters needed by the system


Nightwatch:

Probabilistic Auditing

We target systems that do not require immediate detection

Local auditors randomly look for unsatisfied invariants between fixed intervals of time

This approach is attractive for large-scale systems that cannot rely on a vast amount of resources


Nightwatch:

Interface to Auditing System

Service Modeling Language (SML)

– XML-based specification proposed by information technology companies

– Defines a consistent way to express how computer networks, applications, servers and other IT resources are described or modeled

– Allows easy management of services built on these resources


Nightwatch:Case Study: Multimedia Dissemination

We use auditing to avoid nodes without enough upload capacity from affecting the quality of streaming

We use multiple layers with different download rates based on the upload rates of its members. Higher layers provide higher quality data.

StreamingServer

Interested Peers


Nightwatch:Effect of Auditing on a Sample Stream

70% Rich nodes | 30% Poor nodes

0

0.2

0.4

0.6

0.8

1

0 50 100 150Time (s)

Rat

io o

f rec

eive

d pa

cket

s

Minimum Average Maximum

With AuditingWithout Auditing With AuditingWithout Auditing

200


Nightwatch:

Work in Progress

We are in the initial phase of implementing NightWatch

We are exploring a set of real applications as case studies– DNS, DHTs, Corona


Intrusion-tolerant services in WANS:

Motivation

Intrusion-tolerant services– Pessimistic ([Castro, Liskov 99])– Optimistic ([Abd-el-Malek et al. 05])– Hybrid ([Cowling et al. 06])

Performance vs security

Internet

1011

1011

@$!&


Intrusion-tolerant services in WANs:

Goals and approach

Improve performance of quorum-based schemes Measures:

– Network delay– Network congestion– Load

Framework:– Given:

network (delay, bandwidth) quorum system

– Find quorum placement minimizing delay or congestion


Intrusion-tolerant services in WANs:

Results

Finding optimal placements for arbitrary quorums is NP-hard for both measures

Approximation algorithms:– For network delay, constant approx. for arbitrary

quorum systems if exceed node capacities by small factor

– For congestion, polylog(size of network) approx. for arbitrary graphs, arbitrary quorum systems if exceed node capacity by a factor of 2

Now turning toward empirical evaluations of these techniques

Documents

Trustworthy Systems