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?