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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend