The Evolution of Dyninst in Cyber Security

 
The Evolution of Dyninst
in Support of Cyber Security
 
Emily Gember-Jacobson
What’s interesting about the security context?
 
Programs designed to evade analysts
Precision matters (as always!)
Security policies require new program
modification capabilities
2
The Evolution of Dyninst in Support of Cyber Security
Dyninst on the “offense”
 
What happens when programs are designed to evade analysts?
Anti-analysis tricks
Obfuscated control flow
Unpacked code
Overwritten code
Anti-instrumentation tricks
PC-sensitive code
Anti-patching
Address-space probing
3
The Evolution of Dyninst in Support of Cyber Security
Dyninst on the “defense”
 
Another security goal: 
ensure that a program executes
in the way intended by its authors
 
Protecting programs (first- or third-party) may require
capabilities that we have not needed in the past
System call monitoring
More fine-grained instrumentation
More aggressive and fine-grained modification
4
The Evolution of Dyninst in Support of Cyber Security
 
How have we already adapated?
 
More robust analysis and instrumentation
Nate, Kevin, Drew, Bill
Hybrid static + dynamic analysis
Kevin
 
Binary modification
Drew, Bill, Wenbin
 
New events in ProcControl
Emily, Bill
 
5
 
The Evolution of Dyninst in Support of Cyber Security
Better parsing
 
Challenges
Not all binaries contain symbol and other debug info
Code is hard to find
 
ParseAPI helps to overcomes these challenges
Recursive traversal parsing and gap parsing
Leverage machine learning techniques for better
function entry point identification
6
The Evolution of Dyninst in Support of Cyber Security
Hybrid static + dynamic analysis
 
Challenges
Self-modifying programs overwrite code at runtime
Statically un-analyzable control flow hides code
SD-Dyninst approach
7
The Evolution of Dyninst in Support of Cyber Security
Sensitivity analysis and instrumentation
 
Challenges
Instrumentation augments the original code
Instrumentation can affect program behavior and
sometimes cause incorrect execution
How Dyninst handles sensitivities
Goal: preserve visible behavior
Identify sensitive instructions
Compensate for externally-sensitive instructions
8
The Evolution of Dyninst in Support of Cyber Security
call printf
push $(orig_ret_addr)
jmp printf
Binary modification
 
Goals
Changes become part of the original CFG
May alter behavior of the original code
Should not cause unexpected side effects
How Dyninst handles modification
Structured binary editing
Modify binaries by transforming their CFGs
Ensure validity of the resulting binary
PatchAPI
Interactive CFG modification
Mix modification and instrumentation
 
9
The Evolution of Dyninst in Support of Cyber Security
 
System call monitoring
 
Goals
Identify system call events during program execution
Extract interesting information at these events
 
How ProcControlAPI handles this (in v8.2)
Leverage ptrace (Linux only)
Differentiate between entry and exit events
Similar interface as other ProcControl events
 
10
 
The Evolution of Dyninst in Support of Cyber Security
 
Where are we now?
 
Ability to analyze packed malware
 
Binary modification
 
System call events
 
11
 
The Evolution of Dyninst in Support of Cyber Security
 
What we’re currently working on
 
Ongoing updates to precise handling of
program semantics
 
Stack frame modification
 
Extended first-party instrumentation
 
12
 
The Evolution of Dyninst in Support of Cyber Security
Stack frame modifications
One use case: insertion of stack canaries
13
The Evolution of Dyninst in Support of Cyber Security
original
 
modified
 
Stack frame modifications
 
Other possibilities
Add stack-based local variables
Reorder local variables for security or
software diversification
Remove unused variables
ABI changes
 
14
 
The Evolution of Dyninst in Support of Cyber Security
Stack frame sensitivity
Program may be sensitive to these modifications
15
The Evolution of Dyninst in Support of Cyber Security
push %rbp
mov %rsp, %rbp
mov 0x10(%rbp),%rdx
registers
original
 
Assembly for 
bar
 
modified
 
canary
push canary value onto stack
 
0x18
 
sensitive 
Stack frame
for 
foo
Stack frame
for 
bar
Stack frame sensitivity
  
 
An operation is 
sensitive
 if it accesses stack memory
via a calculated relative distance that is changed.
 
Our next steps:
Formal model of stack frame sensitivity
Update Dyninst with the analysis and
compensation logic needed to handle this
sensitivity during instrumentation
16
The Evolution of Dyninst in Support of Cyber Security
Complete deployment
Extended first-party instrumentation
17
The Evolution of Dyninst in Support of Cyber Security
complete executable
dynamically-
linked libraries
dynamically-
generated code
dynamically-
loaded libraries
executable file
libD.so
JIT’d code
libA.so
libB.so
dynamically-
linked libraries
libA.so
libB.so
source code
names of
dynamically-
linked libraries
 
Complete deployment
 
Extended first-party instrumentation
 
Our next steps
Enable Dyninst to instrument shared libraries as
they load during program startup and via 
dlopen
Enable Dyninst to detect dynamically-generated
code (e.g., JIT’d code) during program execution
 
18
 
The Evolution of Dyninst in Support of Cyber Security
Conclusion
 
Extending Dyninst to support security projects
enhances Dyninst features for all users
Upcoming new features
Stack frame modifications
Extended first-party instrumentation
 
 
 
Questions?
19
The Evolution of Dyninst in Support of Cyber Security
Slide Note
Embed
Share

The evolution of Dyninst in support of cyber security explores various aspects including different types of binary programs, security challenges, offensive and defensive strategies, adaptation techniques, better parsing methods, and the use of hybrid static and dynamic analysis. The content highlights the importance of precision, program modification capabilities, and the need for protecting programs while dealing with security threats in the cyber domain.


Uploaded on Sep 07, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. The Evolution of Dyninst in Support of Cyber Security Emily Gember-Jacobson Paradyn Project Dyninst/MRNet Users Meeting Madison, Wisconsin August 7, 2014

  2. Whats interesting about the security context? Friendly binary Uncooperative binary Hostile binary Programs designed to evade analysts Precision matters (as always!) Security policies require new program modification capabilities 2 The Evolution of Dyninst in Support of Cyber Security

  3. Dyninst on the offense What happens when programs are designed to evade analysts? Anti-analysis tricks Obfuscated control flow Unpacked code Overwritten code Anti-instrumentation tricks PC-sensitive code Anti-patching Address-space probing 3 The Evolution of Dyninst in Support of Cyber Security

  4. Dyninst on the defense Another security goal: ensure that a program executes in the way intended by its authors Protecting programs (first- or third-party) may require capabilities that we have not needed in the past System call monitoring More fine-grained instrumentation More aggressive and fine-grained modification 4 The Evolution of Dyninst in Support of Cyber Security

  5. How have we already adapated? More robust analysis and instrumentation Nate, Kevin, Drew, Bill Hybrid static + dynamic analysis Kevin Binary modification Drew, Bill, Wenbin New events in ProcControl Emily, Bill 5 The Evolution of Dyninst in Support of Cyber Security

  6. Better parsing Challenges Not all binaries contain symbol and other debug info Code is hard to find ParseAPI helps to overcomes these challenges Recursive traversal parsing and gap parsing Leverage machine learning techniques for better function entry point identification 6 The Evolution of Dyninst in Support of Cyber Security

  7. Hybrid static + dynamic analysis Challenges Self-modifying programs overwrite code at runtime Statically un-analyzable control flow hides code SD-Dyninst approach Parse from known entry points Instrument control flow that may lead to new code Resume execution instrument overwrite exception CALL ptr[eax] DIV eax, 0 7 The Evolution of Dyninst in Support of Cyber Security

  8. Sensitivity analysis and instrumentation Challenges Instrumentation augments the original code Instrumentation can affect program behavior and sometimes cause incorrect execution How Dyninst handles sensitivities Goal: preserve visible behavior Identify sensitive instructions Compensate for externally-sensitive instructions push $(orig_ret_addr) jmp printf call printf 8 The Evolution of Dyninst in Support of Cyber Security

  9. Binary modification Goals Changes become part of the original CFG May alter behavior of the original code Should not cause unexpected side effects How Dyninst handles modification Structured binary editing Modify binaries by transforming their CFGs Ensure validity of the resulting binary PatchAPI Interactive CFG modification Mix modification and instrumentation 9 The Evolution of Dyninst in Support of Cyber Security

  10. System call monitoring Goals Identify system call events during program execution Extract interesting information at these events How ProcControlAPI handles this (in v8.2) Leverage ptrace (Linux only) Differentiate between entry and exit events Similar interface as other ProcControl events 10 The Evolution of Dyninst in Support of Cyber Security

  11. Where are we now? Ability to analyze packed malware Binary modification System call events 11 The Evolution of Dyninst in Support of Cyber Security

  12. What were currently working on Ongoing updates to precise handling of program semantics Stack frame modification Extended first-party instrumentation 12 The Evolution of Dyninst in Support of Cyber Security

  13. Stack frame modifications One use case: insertion of stack canaries original modified return address return address return address return address canary local variables local variables 13 The Evolution of Dyninst in Support of Cyber Security

  14. Stack frame modifications Other possibilities Add stack-based local variables Reorder local variables for security or software diversification Remove unused variables ABI changes 14 The Evolution of Dyninst in Support of Cyber Security

  15. Stack frame sensitivity Program may be sensitive to these modifications original modified registers return address return address rdx Stack frame for foo rbp return address return address canary Stack frame for bar Assembly for bar push %rbp mov %rsp, %rbp mov 0x10(%rbp),%rdx push canary value onto stack 0x18 sensitive 15 The Evolution of Dyninst in Support of Cyber Security

  16. Stack frame sensitivity An operation is sensitive if it accesses stack memory via a calculated relative distance that is changed. Our next steps: Formal model of stack frame sensitivity Update Dyninst with the analysis and compensation logic needed to handle this sensitivity during instrumentation 16 The Evolution of Dyninst in Support of Cyber Security

  17. Complete deployment Extended first-party instrumentation executable file complete executable depends on libA.so libB.so linked libraries source code names of dynamically- executable file libA.so dynamically- linked libraries libB.so libA.so dynamically- linked libraries libB.so dynamically- loaded libraries libD.so dynamically- generated code JIT d code 17 The Evolution of Dyninst in Support of Cyber Security

  18. Complete deployment Extended first-party instrumentation Our next steps Enable Dyninst to instrument shared libraries as they load during program startup and via dlopen Enable Dyninst to detect dynamically-generated code (e.g., JIT d code) during program execution 18 The Evolution of Dyninst in Support of Cyber Security

  19. Conclusion Extending Dyninst to support security projects enhances Dyninst features for all users Upcoming new features Stack frame modifications Extended first-party instrumentation Questions? 19 The Evolution of Dyninst in Support of Cyber Security

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#