1 / 45

Trustworthy Systems

Trustworthy Systems. Group Leaders: Alex Aiken Mike Reiter David Wagner. Scope. Includes at least Trustworthiness via software analysis Trustworthiness via hardware assist Trustworthiness by distribution

egan
Download Presentation

Trustworthy Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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 Trustworthy Systems

  3. Trustworthiness via Software Analysis

  4. 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) Trustworthy Systems

  5. EXE:Goal: find bugs in systems code • 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. int bad_abs(int x) { if(x < 0) return –x; if(x == 12345678) return –x; return x; } Trustworthy Systems

  6. EXE:EXecution generated Executions • 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! Trustworthy Systems

  7. EXE:The toy example • Initial state: x unconstrained • Code will return 3 times. • Solve constraints at each return = 3 test cases. 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; } Trustworthy Systems

  8. 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. Trustworthy Systems

  9. EXE:Trend: mount untrusted disks • Removable device (USB stick, CD, DVD) • Let untrusted user mount files as disk images Trustworthy Systems

  10. 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! Trustworthy Systems

  11. EXE:A galactic view 1 User-Mode-Linux 4 5 2 3 ext3 Unmodified Linux EXE-cc instrumented Trustworthy Systems

  12. 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! Trustworthy Systems

  13. EXE:Generated disk of death (JFS, Linux 2.4.19, 2.4.27, 2.6.10) Create 64K file, set 64th sector to above. Mount. And PANIC your kernel! Trustworthy Systems

  14. 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 symbolic block + count can overflow and becomes negative! Pass block to bar block_group is symbolic block can be large! Symbolic read off bound Symbolic write off bound Trustworthy Systems

  15. 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. Trustworthy Systems

  16. 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) Trustworthy Systems

  17. Joe-E: The approach Global variablesconsidered harmful Languages withlexical scoping All variables haveglobal scope (poor practice) (better practice) (language support) Privilege separation:privs are module-local All privilegesglobally accessible Joe-E: global scopeprovides no privilege Trustworthy Systems

  18. Security via Static Analysis: Goals State of the art • 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 Trustworthy Systems

  19. Security via Static Analysis:Example: User/Kernel Bugs 4GB 4GB kernel kernel 3GB 3GB user user unmapped unmapped user 0 0 • 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 Trustworthy Systems

  20. 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 Trustworthy Systems

  21. Security via Static Analysis: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 Trustworthy Systems

  22. Security via Static Analysis: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 Trustworthy Systems

  23. Security via Static 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 . . . Trustworthy Systems

  24. Trustworthiness via Hardware Assist

  25. Spotlight • Nexus operating system for trustworthy computing • Emin Gün Sirer, Fred B. Schneider (Cornell) Trustworthy Systems

  26. 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 Trustworthy Systems

  27. 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 Trustworthy Systems

  28. 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 Trustworthy Systems

  29. 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. Trustworthy Systems

  30. 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 Trustworthy Systems

  31. 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 Trustworthy Systems

  32. Nexus: Organization Trustworthy Systems

  33. Trustworthiness by Distribution

  34. 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) Trustworthy Systems

  35. Nightwatch:Motivation • Distributed systems are complex • Unexpected failures may occur • Software bugs • Network failures • Unpredicted load • Improper tuning • Rational or malicious behavior Trustworthy Systems

  36. Nightwatch:Hybrid auditing model • Hybrid global + local auditors scheme • Probabilistic querying • Internal fault tolerance • Adaptivity to current conditions Trustworthy Systems

  37. 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 Trustworthy Systems

  38. 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 Trustworthy Systems

  39. 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 Trustworthy Systems

  40. 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. Trustworthy Systems

  41. Nightwatch:Effect of Auditing on a Sample Stream 70% Rich nodes | 30% Poor nodes Trustworthy Systems

  42. 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 Trustworthy Systems

  43. 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 1011 Internet @$!& 1011 Trustworthy Systems

  44. 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 Trustworthy Systems

  45. 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 Trustworthy Systems

More Related