1 / 37

CompSci 725 Presentation

CompSci 725 Presentation. by Siu Cho Jun, William. CompSci 725 Presentation. Playing Inside the Black Box: Using Dynamic Instrumentation to Create Security Holes by Barton P. Miller, Mihai Christodorescu, Robert Iverson, Tevfik Kosar, Alexander Mirgorodskii, Florentina Popovici.

quincy-mcneil
Télécharger la présentation

CompSci 725 Presentation

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. CompSci 725 Presentation by Siu Cho Jun, William

  2. CompSci 725 Presentation Playing Inside the Black Box: Using Dynamic Instrumentation to Create Security Holes by Barton P. Miller, Mihai Christodorescu, Robert Iverson, Tevfik Kosar, Alexander Mirgorodskii, Florentina Popovici

  3. CompSci 725 Presentation • Computer Sciences Department, University of Wisconsin • Paradyn Project • Exploring new approaches to build scalable tools for monitoring or tuning of parallel program performance.

  4. Outline • Introduction • The Aim of this paper • Background • What is “DynInst”? • Demo 1 • Demo 2 • Conclusion

  5. Introduction • Programs in execution have long been considered to be immutable objects • Use “DynInst API” to build tools • Operate on binary codes during execution

  6. Introduction • Show how Dynamic Instrumentation techniques can be used to subvert system security through vulnerabilities • Provide some suggestions to compromise those vulnerabilities

  7. Background • What is “DynInst”? • A post-compiler program manipulation tool • Provides an Application Program Interface (API) for programming instrumentation tools with the dynamic instrumentation technology • C++ class library

  8. Background • What is “DynInst”? (cont.) • Allows tool builders build tools that can make insertion and modification to a running program • Without re-compile, re-link, or even re-execute the program • Machine independent

  9. Background • What can tools built with “DynInst API” do? • (1) inspect a running process, obtaining structural information about the program; • (2) control the execution of the program; • (3) cause new libraries to be dynamically loaded into the process' address space;

  10. Background • What can tools built with “DynInst API” do? (cont.) • (4) splice new code sequences into the running program and remove them; • (5) replace individual call instructions or entire functions.

  11. Background • Terms: • Mutator • The tool built for performing instrumentation • Mutatee • The program to be instrumented • Point • A location in a program where instrumentation can be inserted • Snippet • A piece of executable code to be inserted into a program at a point

  12. Background • How it works? p.s. Image extracted from the paper “Playing Inside the Black Box: Using Dynamic Instrumentation to Create Security Holes”

  13. Background • How it works? p.s. Image extracted from the paper “An API for Runtime Code Patching”

  14. Demo 1 The Lurking Condor Job • Goal • To expose security vulnerabilities in a distributed computing environment

  15. Demo 1 • Background Info. • Platform: Unix with Condor • High-Throughput Computing System • allows users to schedule and run application programs on idle hosts in widely distributed environment • Users do not need to have account and privileges on other hosts

  16. Demo 1 • Condor • SM: Submitting Machine • EM: Execution Machine

  17. Demo 1 • Attack strategy

  18. Demo 1 • Attack strategy

  19. Demo 1 • Attack strategy

  20. Demo 1 • Attack strategy

  21. Demo 1 • Attack strategy

  22. Demo 1 • Vulnerability of Condor System • Condor starts a shadow process on the SM when it starts the submitted program on the remote EM • The shadow process receives remote system calls from the EM and executes with the normal privileges of the submitting user

  23. Demo 1 • Vulnerability of Condor System (cont.) • EM might subvert the submitted program and cause it to make inappropriate and malicious requests to the user's SM • Condor use the same user id for every job on the EM, this allow the lurker process to access subsequently arriving jobs

  24. Demo 1 • Suggestions: • On SM • Create “Sandbox” around the shadow process • On trusted EM • Restrict the use of system call on EM • Clear up after a job migrated or completed • Use multiple user ID’s • Malicious EM can bypass any of those measures

  25. Demo 2 Subverting License Checking • Goal • Use DynInst tools to bypass license checking • And attain full program functionality even when the license data could not be obtained

  26. Demo 2 • Background Info. • Target application: Framemaker word processing tool from Adobe • Platform: UltraSPARC IIi running Solaris • License checking method in Framemaker: Obtain license data from license server and validate it

  27. Demo 2 • Attack Strategy • (1) See the program as a black box and capture the I/O operations to located those were specific to contacting the license server • Attach DynInst to Framemaker and trace all library functions that performs I/O operations • Replace the open, read, write, send, and recv library function with custom versions which are modified to copy their data into a mirror file

  28. Demo 2 • Attack Strategy • (2) Trace the flow control within the program to understand where the license checking is performed • By tracing the control flow for the cases: • the license server is successfully contacted • the license server cannot be contacted

  29. Demo 2 • Attack Strategy • (3) Determine the functions to be skipped or replaced to avoid the failure of the license check

  30. Demo 2 • Attack toolkit • (1) Function Call Tracer • The depth of the call stack, order of calls, and return values from each function are reported • (2) Function Argument Parser • For tracking the type and name of each parameter to a function in the application

  31. Demo 2 • Attack toolkit • (3) Java to DynInst Compiler (JavaD) • Since the DynInst API calls operate at the machine language level • Write snippet in Java and translate to DynInst calls • To simplify the task of creating code snippets

  32. Demo 2 • Result • Successfully bypassed the licensing checks by the following steps: • (1) Allowed the retrieval of the license data to fail. • (2) Prevented FrameMaker from entering demo mode by deleting the function call of ChangeProductToDemo.

  33. Demo 2 • Result (cont.) • (3) Bypassed the first license data validation by skipping over the sequence of code that performed it. • (4) Modified all later license data validations to always succeed, regardless of the presence of the license data in memory.

  34. Demo 2 • Suggestion • Basic code obfuscation techniques can be used: • obscure naming of modules and functions • violating modularity by having many implementations of the same functionality especially for the license checking function • Include error reporting code

  35. Conclusion • With DynInst library: • It is easy to monitor and control almost any running program. • It is also easy to make arbitrary changes that program's behavior.

  36. Conclusion • More significant study is needed for Safe remote execution which includes: • preventing inappropriate operations • preventing undetected modification or spoiling of computational results

  37. Question • We have seen several tamper-proofing/tamper-resistance technique: • Software Guards • Obfuscation • Software aging • How well do they serve in protecting software?

More Related