Paradyn Project Paradyn / Dyninst Week College Park, Maryland March 26-28, 2012 Self-propelled Instrumentation Wenbin Fang.

Slides:



Advertisements
Similar presentations
Self-Propelled Instrumentation Alex Mirgorodskiy Barton Miller Computer Sciences Department University.
Advertisements

SDN Controller Challenges
A Process Splitting Transformation for Kahn Process Networks Sjoerd Meijer.
Advanced topics in X86 assembly by Istvan Haller.
Chorus and other Microkernels Presented by: Jonathan Tanner and Brian Doyle Articles By: Jon Udell Peter D. Varhol Dick Pountain.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin May 2-4, 2011 ProcControlAPI and StackwalkerAPI Integration into Dyninst Todd Frederick and Dan.
Paradyn Project Paradyn / Dyninst Week College Park, Maryland March 26-28, 2012 Paradyn Project Upcoming Features in Dyninst and its Components Bill Williams.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin May 2-3, 2011 Introduction to the PatchAPI Wenbin Fang, Drew Bernat.
U NIVERSITY OF M ASSACHUSETTS, A MHERST Department of Computer Science Emery Berger University of Massachusetts Amherst Operating Systems CMPSCI 377 Lecture.
COS 461 Fall 1997 Where We Are u so far: networking u rest of semester: distributed computing –how to use networks to do interesting things –connection.
Distributed Self-Propelled Instrumentation Alex Mirgorodskiy VMware, Inc. Barton P. Miller University of Wisconsin-Madison.
TaintCheck and LockSet LBA Reading Group Presentation by Shimin Chen.
Run time vs. Compile time
1 Run time vs. Compile time The compiler must generate code to handle issues that arise at run time Representation of various data types Procedure linkage.
Processes in Unix, Linux, and Windows CS-502 Fall Processes in Unix, Linux, and Windows CS502 Operating Systems (Slides include materials from Operating.
FALL 2005CSI 4118 – UNIVERSITY OF OTTAWA1 Part 4 Web technologies: HTTP, CGI, PHP,Java applets)
Previous Next 06/18/2000Shanghai Jiaotong Univ. Computer Science & Engineering Dept. C+J Software Architecture Shanghai Jiaotong University Author: Lu,
Automated Tracing and Visualization of Software Security Structure and Properties Symposium on Visualization for Cyber Security 2012 (VizSec’12) Seattle,
Security Exploiting Overflows. Introduction r See the following link for more info: operating-systems-and-applications-in-
A Mobile-Agent-Based Performance-Monitoring System at RHIC Richard Ibbotson.
Paradyn Project Dyninst/MRNet Users’ Meeting Madison, Wisconsin August 7, 2014 The Evolution of Dyninst in Support of Cyber Security Emily Gember-Jacobson.
University of Maryland parseThat: A Robust Arbitrary-Binary Tester for Dyninst Ray Chen.
Introduction - What is Jini Technology?
University of Washington Today Memory layout Buffer overflow, worms, and viruses 1.
Instrumentation - initial results Sung Kim, Jeff Perkins MIT.
Support for Debugging Automatically Parallelized Programs Robert Hood Gabriele Jost CSC/MRJ Technology Solutions NASA.
Analysis Of Stripped Binary Code Laune Harris University of Wisconsin – Madison
The Deconstruction of Dyninst: Experiences and Future Directions Drew Bernat, Madhavi Krishnan, Bill Williams, Bart Miller Paradyn Project 1.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Avira Endpoint Security. Introduction of Avira Management Center (AMC)
University of Washington Today Happy Monday! HW2 due, how is Lab 3 going? Today we’ll go over:  Address space layout  Input buffers on the stack  Overflowing.
Procedures – Generating the Code Lecture 21 Mon, Apr 4, 2005.
CE Operating Systems Lecture 13 Linux/Unix interprocess communication.
CS216: Program and Data Representation University of Virginia Computer Science Spring 2006 David Evans Lecture 22: Unconventional.
Root Cause Analysis of Failures in Large-Scale Computing Environments Alex Mirgorodskiy, University of Wisconsin Naoya Maruyama, Tokyo.
Debugging TI RTOS TEAM 4 JORGE JIMENEZ JHONY MEDRANO ALBIEN FEZGA.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin April 12-14, 2010 Binary Rewriting with Dyninst Madhavi Krishnan and Dan McNulty.
Argos Emulator Georgios Portokalidis Asia Slowinska Herbert Bos Vrije Universiteit Amsterdam.
Dr. Sajib Datta CSE Spring 2016 INTERMEDIATE PROGRAMMING.
Source Level Debugging of Parallel Programs Roland Wismüller LRR-TUM, TU München Germany.
© 2006 Andrew R. BernatMarch 2006Generalized Code Relocation Generalized Code Relocation for Instrumentation and Efficiency Andrew R. Bernat University.
13/July/1999Third USENIX Windows NT Symposium1 Detours: Binary Interception of Win32 Functions Galen Hunt and Doug Brubacher Systems and Networking Group.
© 2001 Week (14 March 2001)Paradyn & Dyninst Demonstrations Paradyn & Dyninst Demos Barton P. Miller Computer.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin April 29-May 1, 2013 Detecting Code Reuse Attacks Using Dyninst Components Emily Jacobson, Drew.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin May 2-4, 2011 Paradyn Project Deconstruction of Dyninst: Best Practices and Lessons Learned Bill.
Operating Systems Unit 2: – Process Context switch Interrupt Interprocess communication – Thread Thread models Operating Systems.
1 Xen and the Art of Binary Modification Lies, Damn Lies, and Page Frame Addresses Greg Cooksey and Nate Rosenblum, March 2007.
1NinjaScript Presentation CS264December 2, 1998 NinjaScript A Dataflow Language for Composing Network Services in Ninja Andrew Begel.
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin May 2-4, 2011 unstrip: Restoring Function Information to Stripped Binaries Using Dyninst Emily.
Correct RelocationMarch 20, 2016 Correct Relocation: Do You Trust a Mutated Binary? Drew Bernat
Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin April 12-14, 2010 Paradyn Project Safe and Efficient Instrumentation Andrew Bernat.
Distributed Systems1 Socket API  The socket API is an Interprocess Communication (IPC) programming interface originally provided as part of the Berkeley.
Constraint Framework, page 1 Collaborative learning for security and repair in application communities MIT site visit April 10, 2007 Constraints approach.
Program Execution in Linux David Ferry, Chris Gill CSE 522S - Advanced Operating Systems Washington University in St. Louis St. Louis, MO
Remix: On-demand Live Randomization
Buffer Overflow Buffer overflows are possible because C doesn’t check array boundaries Buffer overflows are dangerous because buffers for user input are.
Kernel Code Coverage Nilofer Motiwala Computer Sciences Department
The Hardware/Software Interface CSE351 Winter 2013
Program Execution in Linux
CSC 495/583 Topics of Software Security Return-oriented programming
Procedures – Overview Lecture 19 Mon, Mar 28, 2005.
Assembly Language Programming II: C Compiler Calling Sequences
Optimizing Your Dyninst Program
Efficient x86 Instrumentation:
Program Execution in Linux
Lecture 6: RPC (exercises/questions)
Lecture 6: RPC (exercises/questions)
Lecture 7: RPC (exercises/questions)
System and Cyber Security
Return-to-libc Attacks
Presentation transcript:

Paradyn Project Paradyn / Dyninst Week College Park, Maryland March 26-28, 2012 Self-propelled Instrumentation Wenbin Fang

Overview o Self-propelled instrumentation o Inject a fragment of code into the target process o Instrumentation automatically follows control flow o Within process o Cross process / host boundary o Features o 1 st party execution in the same address space o On demand, function call level instrumentation o Applications o Fault diagnosis, security analysis, … Self-propelled Instrumentation 2

Application Process Big Picture o Injector: Process to inject shared library o Agent: Shared library o User-specified payload functions o Instrumentation engine Self-propelled Instrumentation Injector process 3 a.out libc.so libpthread.so Agent.so Payload Functions Instrumentation Engine

void payload(SpPoint* pt){ // Do something } How it works void main () { pthread_create(foo …) printf(…) } void foo () { connect(…) } Self-propelled Instrumentation Host A Host B Process P Process Q Agent.so network Process R Injector 4 Call

Reincarnation Previous life (2006) o Parallel implementation with Dyninst o x86 Linux o For research on fault diagnosis [ 1 ] Reincarnation (2012) o Leverage Dyninst toolkits o x86/x86_64 Linux o Initially for security analysis, also for more applications [ 1 ] Alexander Vladimirovich Mirgorodskiy, "Automated problem diagnosis in distributed systems", Doctoral dissertation, University of Wisconsin-Madison, Madison, WI, USA, Self-propelled Instrumentation 5

Injector o Inject a shared library before a process executes o Use dynamic linking to load agent (LD_PRELOAD) o Inject a shared library for a process in execution o Use Dyninst toolkit (ProcControlAPI) Self-propelled Instrumentation 6

Agent – Contents o User-provided payload functions o Entry payload: executed before each function call o Exit payload: executed after each function call o Instrumentation Engine o Mainly based on PatchAPI o Also based on other Dyninst toolkits, e.g., Stackwalker, InstructionAPI, … Self-propelled Instrumentation 7

Agent – In payload function o Query PatchAPI CFG structures o Functions / Basic blocks / Edges o Enables sophisticated code analysis o Query runtime information related to the current function call o Arguments / Return value o Detect system events o Communication events, e.g., send/recv o Security events, e.g., setuid Self-propelled Instrumentation 8

Example: Print func names and # of calls to printf Self-propelled Instrumentation void main () { printf(…); foo(); … } void foo() { printf(); } Agent.so void payload(SpPoint* pt) { // Print Callee Name // Print count of printf } Output: CALL: printf # printf: 1 CALL: foo CALL: printf # printf: 2 9 Call

Payload functions Single-threaded, single process int count = 0; void payload(SpPoint* pt) { PatchFunction* f = Callee(pt); if (!f) return; string name = f->name(); printf(“CALL:%s\n”,name.c_str()); if (name.compare(“printf”)==0){ ++count; printf(“# printf: %d\n”,count); } Propel(pt); } Multi-threaded, single process Self-propelled Instrumentation 10 int count = 0; SpLock count_lock = 0; void payload(SpPoint* pt) { PatchFunction* f = Callee(pt); if (!f) return; string name = f->name(); printf(“CALL:%s\n”,name.c_str()); if (name.compare(“printf”)==0){ sp::Lock(&count_lock); ++count; sp::Unlock(&count_lock); printf(“# printf: %d\n”,count); } Propel(pt); }

Intra-process propagation Self-propelled Instrumentation a.out main 8430: 8431: 8433: 8444: 8449: 844b: 844e: 844f: push %ebp mov %esp,%ebp... call printf mov %ebp,%esp xor %eax,%eax pop %ebp ret foo call jmp Patch1 payload(foo) foo 0x8405 Agent.so call jmp payload(printf) printf 0x8449 Patch2 patch jmp push %ebp mov %esp,%ebp... call foo mov %ebp,%esp pop %ebp ret 83f0: 83f1: 83f3: 8400: 8405: 8413: 8414: Inject ActivatePropagate 11 jmp Patch1 jmp Patch2

Intra-process propagation challenges o Instrumentation Engine o Call insn size < jump insn size o Call block size < jump insn size o Cannot find a suitable springboard Self-propelled Instrumentation Relocate call block Find springboard block Use trap or ignore 12

Example: Print remote process name Host : 5370 Self-propelled Instrumentation void main () { connect(…) recv(…) send(…) } Output for :5370: CONNECT: ( :5370, :8080) READ FROM: :8080 WRITE TO: :8080 Agent.so void payload(SpPoint* pt) { // Print remote process Name } Host : 8080 void main () { accept(…) send(…) recv(…) } Output for :8080: ACCEPT: ( :8080, :5370) WRITE TO: :5370 READ FROM: :5370 Agent.so void payload(SpPoint* pt) { // Print remote process name } Call payload 13

Payload functions for IPC Self-propelled Instrumentation 14 Utilities o Detect communication events. o Get process name o e.g., :8080 IPC mechanisms o Pipe o TCP void payload(SpPoint* pt) { PatchFunction* f = sp::Callee(pt); if (!f) return; if (IsConnect(f)) { fprintf(fp, “CONNECT: (%s, %s)\n”, LocalProcessName(), RemoteProcessName()); } else if (IsIpcWrite(f)) { fprintf(fp, “WRITE TO: %s\n”, RemoteProcessName()); } else if (IsIpcRead(f)) { fprintf(fp, “READ FROM: %s\n”, RemoteProcessName()); } sp::Propel(pt); }

Inter-process propagation o Main procedure for inter-process propagation 1.Detect the initiation of communication at the local site. o connect, write, send … 2.Identify the remote process 3.Inject the agent into the remote process 4.Start following the flow of control in the remote site Self-propelled Instrumentation void main () { connect(…) recv(…) } void main () { accept(…) send(…) } Agent.so inject call payload() 15 Process A Process B via ssh / scp

Applications o Existing : o Fault diagnosis in distributed systems o Software security analysis o Potential: o Error reporting in distributed systems o Performance profiling o Consistency analysis in distributed systems o Taint checking o More... Self-propelled Instrumentation 16

Status and Future work o Status o x86 / x86_64 Linux o IPC: pipe, tcp o Testing and debugging to make it robust enough to work on complex programs, e.g., Google Chrome o Future work o Develop tools for software security analysis o Support more protocols / mechanisms for inter- process propagation o Port to Microsoft Windows Self-propelled Instrumentation 17

Questions? Self-propelled Instrumentation 18