orchestra intrusion detection using parallel execution
play

Orchestra: Intrusion Detection Using Parallel Execution and - PowerPoint PPT Presentation

Orchestra: Intrusion Detection Using Parallel Execution and Monitoring of Program Variants in User-Space Babak Salamat, Todd Jackson , Andreas Gal, and Michael Franz Secure Systems and Languages Laboratory Department of Computer Science


  1. Orchestra: Intrusion Detection Using Parallel Execution and Monitoring of Program Variants in User-Space Babak Salamat, Todd Jackson , Andreas Gal, and Michael Franz Secure Systems and Languages Laboratory Department of Computer Science University of California, Irvine EuroSys 2009, April 2009 1

  2. Multi-Variant Execution Variant 1 Variant 2 Variant 1 Variant 2 2

  3. Detection Requirements  Lock-step execution  Feed all variants with identical input  Variants which behave differently when attacked 3

  4. Reverse Stack Growth Direction  Stack objects are located in opposite positions Downward Upward Growing Stack Growing Stack Caller Data Return Address Free Space Return Address Frame Pointer . Other Data . . Buffer Buffer . . Other Data . Frame Pointer Return Address Free Space Return Address Caller Data 4

  5. 5

  6. From Source to Execution Modified Modified Multi- Source Compiler Library Variant Code (GCC 4.2) (Dietlibc) Execution Modified RTL generation Modified code generation Modified assembly Implemented the code of the library multi-variant monitor ~10,000 LoC in C++ 6

  7. Orchestra Architecture  The monitor is a user-space application Diversified Application ... Variant 1 Variant n Library 1 Library n Conventional Application Multi-Variant Monitor Library Untrusted Trusted Operating System 7

  8. Granularity of Monitoring  Granularity of monitoring and Synchronization  Ideally after each instruction  Not always possible  Performance issues  Synchronize and monitor at system calls  No harm is done without invoking a system call  All instances must invoke the same syscall with equivalent arguments 8

  9. System Call Monitoring  Debugging facility of Linux (ptrace) is used to build the monitor  The monitor is notified twice per system call Variant 1 Variant 2 Monitor Syscall Syscall 9

  10. System Call Monitoring (cont.)  Equivalency is checked at the beginning of a system call  The system calls must be the same  Arguments must be equivalent  Pointers (buffers) have the same content  Values are identical  Results of the system call are written back to the variants at the end of the system call if needed 10

  11. System Call Execution  Non-state changing system call that produce immutable results are executed by all Variant 1 Variant 1 Variant 2 Variant 2 uname uname Monitor Monitor uname uname 11

  12. System Call Execution (cont.)  State changing system calls are executed by the monitor Variant 1 Variant 1 Variant 1 Variant 2 Variant 2 Variant 2 Monitor Monitor write(stdout) skipped skipped Monitor write(stdout) write(stdout) write(stdout) skipped skipped 5 5 5 12

  13. System Call Execution (cont.)  Non-state changing system call that produce non- immutable results are executed by all, results are copied from the first variant to all Variant 1 Variant 1 Variant 2 Variant 2 gettime gettime Monitor Monitor 8:00 8:01 8:00 8:00 gettime gettime 13

  14. Data Transfer  ptrace transfers only 4 bytes at a time  very slow in transferring large buffers Variant 1 Monitor 4K Buffer 1000 ptrace calls 14

  15. Data Transfer (cont.)  We tried using named pipes, but they cannot transfer more than 4K bytes at a time  Shared memory is fast and can transfer mega bytes Variant 1 Shared my Monitor Buffer memcpy memory 15

  16. Data Transfer Performance Shared memory is about 1000 times faster than ptrace and 20 times faster than FIFO in transferring a 128K buffer )*+,-." /0/1" 23,+.4"5.67+8" !#####" !"#$%&'()*+&(,-*./0%&.01'%2( !####" !###" !##" !#" !" $" %&" !&$" '!&" &(" $(" %&(" !&$(" 345&/(6*7&(,389&%2( 16

  17. Variant 1 Variant 2 Removing False Positives False positives are the major practical issue in using multi-variant execution 17

  18. Multi-Threaded Variants  Different scheduling of multi-threaded or multi-process applications can cause false positives Variant 2 Variant 1 Thread 2 Thread 2 read read write write Variant 1 Variant 2 Thread 1 Thread 1 18

  19. Monitoring multi-threaded variants  Corresponding threads/processes must be synchronized to each other Variant 1 Variant 2 Thread 2 Thread 2 Monitor read read Thread 2 Variant 1 Variant 2 Thread 1 Thread 1 Monitor write write Thread 1 19

  20. File Descriptors  The same file descriptor is always reported to all variants when they invoke system calls that return a file descriptor Variant 1 Variant 1 Variant 1 Variant 1 Variant 2 Variant 2 Variant 2 Variant 2 Monitor Monitor Monitor Monitor pipe pipe 11 7 open(1.txt, WR) open(1.txt, WR) pipe pipe skipped 11 9 skipped 5 5 open(1.txt, WR) 20

  21. Process ID  Monitor reports the process ID of the first variant to all  The PID of the first variant’s child process is reported as the result of fork or clone to all the variants Variant 1 Variant 1 Variant 2 Variant 2 PID: 100 PID: 100 PID: 101 PID: 101 Monitor Monitor getpid getpid 100 101 getpid getpid 100 100 21

  22. Process IDs in Arguments  When variants need to run a system call that receives a PID, appropriate PID is restored before the execution of the system call Variant 1 Variant 1 Variant 2 Variant 2 PID: 100 PID: 100 PID: 101 PID: 101 Monitor Monitor kill(100) kill(100) kill(100) kill(101) 22

  23. Asynchronous Signals  Signal handlers can cause different sequences of system calls to be executed by the variants Variant 1 Variant 2 signal handler Syscall 8 Syscall 1 Syscall 1 23

  24. Time and Random Numbers  System calls that read time (e.g., gettimeofday) are executed by one variant and the result is copied to all  By providing identical time and other system information to all variants, they likely use the same seed to generate random numbers  The monitor reads /dev/urandom and copies the result to all variants  Reading CPU time stamp counters (RDTSC) may still cause false positives 24

  25. Performance (!!"# $!"# %!"# &!"# '!"# !"# )*+,-# ./01# .))# 21*# 1+*34*## 14*5678# EF#G<4)?H:B# 7)9# SPEC .+1## 2:*;4<## EE#G<4)?H:B# 6/01$## ;=:59### 4>?+84## F#G<4)?H:B# +*;#### 743+#### +1+)@4# ;+*# ABC# 7CDC441# +24*+.4# 25

  26. Summary  Multi-variant execution is an effective technique in detecting and disrupting attacks  A reverse stack executable can prevent stack-based buffer overflow vulnerabilities in a multi-variant environment  Our methods can remove most sources of false positives in multi-variant execution  Running two parallel variants have about 15% overhead 26

  27. Thank you Questions? 27

Recommend


More recommend