150 likes | 258 Views
A Binary Agent Technology for COTS Software Integrity. Anant Agarwal Richard Schooler InCert Software. Agenda. Objectives & Approach Prototype Progress: Robustness Fine-Grain Application Monitoring Solaris Investigation Integration Opportunities. Objectives & Approach. Focus on:
E N D
A Binary Agent Technology for COTS Software Integrity Anant Agarwal Richard Schooler InCert Software 1
Agenda • Objectives & Approach • Prototype • Progress: • Robustness • Fine-Grain Application Monitoring • Solaris Investigation • Integration Opportunities 2
Objectives & Approach • Focus on: • Deployed applications - not just for development, QA phases. • Inside the application - not just externally-visible behavior. • Approach: • Run-time execution monitoring. • Binary instrumentation to inject probes into release-built executables. 3
Targets & Assumptions • Similarity between explicit attacks and accidental faults. • Assume system-level mechanisms in-place - not guarding against replacement of entire executable, compromise of OS, etc. 4
Major Tasks: • Three Major Components in the Prototype: • Core technology for customizable agent insertion into Windows NT. (And now Solaris.) • Anomaly detection and reporting. • Rapid recovery and problem pinpointing. 5
Binary Instrumentation • At each code block, record progress of program execution. • Snap program/system state based on policy/action. AGENT test al,0x3 jnz 0x1143 1 ... 1 2 4 5 AGENT test al,0x3 jnz 0x1143 2 3 AGENT shr edx,0x1 add ebx,edx 4 AGENT add ebx,ecx jc 0x1101 while ((c = ++ci)) { INSTRUCTION_ITERATOR ii = c->Instructions(); while ((inst = ++ii)) inst->Lift(null_state); while ((inst = ++ii)) inst->Lift(null_state); 5 AGENT inc eax add ecx,edi add edx,esi cmp eax,0xa 6
Snapshot Files Instrumented Executables Executables Map Files Major Components Platform-dependent Instrumentation Engine Runtime Service • Block sequence • User logging • Post-Mortem info • Block->Address Map Trace Reconstruction Debug Info • Source Line/Module • Thread • Annotations • Address<->Line Map • Source Module Name Trace (XML) interface 7
Our runtime failures should not bring down the user’s application! We should be robust in the face of both our own bugs, and external problems, like running out of memory or disk space. Robustness 9
Some techniques: Limit usage of and interference with user-level facilities, like malloc, higher-level file IO, even stack allocation. Exception handling. (But watch out for nested exceptions from exception-handling context…) Desperation buffers. Lock ordering to avoid deadlocking with user code. Robustness, cont. 10
Runtime Architecture Instrumented Application Register with service Service Read initial options Snap requests * User Extension DLL Event notification * buffers InCert runtime • SNMP e-mail • SMTP trap • HTTP • FTP • etc. Attack! • Trace • Memory Dump • Environmental Info (XML) Snapshot file 11
File Management - compression Notification & transportation Heartbeat: is instrumented application still alive? (Auto-notify, and even auto-kill!) Investigating: Monitor distributed applications Monitor un-instrumented components. Service Functionality 12
Solaris Investigation • New binary platform: SPARC ISA (delay slots, register windows), COFF format, ELF/STAB debug format, Solaris signal interface, TSD, etc. • Compilers: Forte (SunPro) & gcc. • Some new issues: • 64 bit support. • How to hook runtime (LD_PRELOAD). • How to get relocation info (no /fixed:no). • Interposition (vs. Detours). • Balance between using Solaris-specific features, and staying generic-Unix-portable. 14
Integration Opportunities • Implementation mechanism for higher-level policies: • Currently hard-wired to trace & snap. • Would like user to be able to specify other policies, triggers and actions: pattern-action language, security automata, etc. • Integration with full-system monitoring: • OS-level (e.g kernel, system call hooking) • Middleware, Scripting languages • Network, Database 15