Download presentation
Presentation is loading. Please wait.
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 Background Demo 1 Demo 2 Conclusion
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
What is “DynInst”? (cont.)
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
What can tools built with “DynInst API” do?
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
What can tools built with “DynInst API” do?
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 Mutatee Point Snippet
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
Vulnerability of Condor System
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
Vulnerability of Condor System (cont.)
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 On trusted EM
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
Subverting License Checking
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?
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.