Trustworthy Systems

1
Trustworthy Systems

• Group Leaders
• Alex Aiken
• Mike Reiter
• David Wagner

2
Scope

• Includes at least
• Trustworthiness via software analysis
• Trustworthiness via hardware assist
• Trustworthiness by distribution
• The primary home for secure systems and
  software research in TRUST

3
Trustworthiness via Software Analysis

• Spotlights
• Joe-E A language for security
• David Wagner
• Static analysis for security
• Alex Aiken and David Wagner

4
Joe-EA 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

5
Joe-E The approach
All variables haveglobal scope
Global variablesconsidered harmful
Languages withlexical scoping
(poor practice)
(better practice)
(language support)
All privilegesglobally accessible
Privilege separationprivs are module-local
Joe-E global scopeprovides no privilege
6
Security via Static Analysis Goals

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

manual audits,grep
Best-effort bugfinding
Soundness
Verify absence of classes of bugs
???
full program verification
7
Security via Static AnalysisExample
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

8
Security via Static Analysis A User/Kernel
Security Hole
Kernel code
int x void sys_setint(int p) memcpy(x, p,
sizeof(x)) void sys_getint(int p) memcpy(p,
x, sizeof(x))

• 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

9
Security via Static AnalysisResearch Issues

• Operating Systems are hard to analyze
• Big Linux has 6MLOC
• Complex High density of tricky code
• Path-sensitive 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

10
Security via Static AnalysisCurrent 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 . . .

11
Trustworthiness via Hardware Assist

• Spotlight
• Minimal TCB code execution
• Adrian Perrig and Mike Reiter

12
Minimal TCB Code ExecutionTrusted Computing
Base (TCB)


App
App 1
App
App 1
S
S
OS
OS
Shim
DMA Devices
DMA Devices
CPU, RAM TPM, Chipset
CPU, RAM TPM, Chipset
(Network, Disk, USB, etc.)
(Network, Disk, USB, etc.)
13
Minimal TCB Code ExecutionContributions

• Isolate security-sensitive code execution from
  all other code and devices
• Convince a remote party that security-sensitive
  code was protected
• Attest to security-sensitive code and its
  arguments and nothing else
• Add lt 250 LoC to the software TCB

S
Software TCB
lt 250 LoC
Shim
14
Minimal TCB Code Execution Architecture Overview

• Exploit capabilities of new commodity CPUs (SVM
  for AMD, TXT for Intel)
• Core technique
• Pause current execution environment
• Execute security-sensitive code with
  hardware-enforced isolation
• Resume previous execution
• Extensions
• Preserve state securely across invocations
• Attest to code execution and protection (and
  nothing else)
• Establish secure communication with remote parties

15
Trustworthiness by Distribution

• Spotlight
• Nightwatch An auditing framework for large scale
  distributed systems
• Robbert van Renesse

16
NightwatchMotivation

• Distributed systems are complex
• Unexpected failures may occur
• Software bugs
• Network failures
• Unpredicted load
• Improper tuning
• Rational or malicious behavior

17
NightwatchHybrid auditing model

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

18
NightwatchProbabilistic 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

19
NightwatchCase 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.