Buffer Overflow Prone Function Detection
1 like853 views
This document proposes identifying buffer overflow inducing loops (BOILs) in binary code as a pattern for detecting buffer overflow vulnerabilities. A BOIL is a loop that writes to memory, where the written address and value change within the loop and depend on function arguments. The authors implemented a tool to detect BOILs using data flow analysis. Experimental results on vulnerable programs found BOILs flagged 10-15% of loops and successfully identified known vulnerabilities. Future work involves integrating BOIL detection into a full vulnerability analysis framework.
![Characterizing the code patterns (1)
Strided memory access pattern within a loop
Pattern A (strcpy function, rather straightforward)
1: regd ← MEM[base+dest] DEST adr.
2: regs ← MEM[base+src] SRC adr.
loop
3: MEM[regd] ← MEM[regs] copy SRC to DEST
4: regd ← regd+stride
5: regs ← regs+stride
endloop
Finding Buffer Overflow Inducing Loops in Binary Executables 15/26](https://image.slidesharecdn.com/main-130102041321-phpapp01/85/Buffer-Overflow-Prone-Function-Detection-17-320.jpg)
![Characterizing the code patterns (2)
pattern B (bufCopy function, less straightforward):
MEM[base+p] ← MEM[base+dest] DEST adr.
loop
1: reg1 ← MEM[base+p]
2: regd ← reg1
3: reg1 ← reg1+stride
4: MEM[base+p] ← reg1 next DEST adr.
5: reg2 ← MEM[base+src] SRC adr
6: regs ← reg2
7: reg2 ← reg2+stride
8: MEM[base+src] ← reg2 next SRC adr.
9: MEM[regd] ← MEM[regs] copy SRC to DEST
endloop
Finding Buffer Overflow Inducing Loops in Binary Executables 16/26](https://image.slidesharecdn.com/main-130102041321-phpapp01/85/Buffer-Overflow-Prone-Function-Detection-18-320.jpg)
![Example on pattern B
code for pattern B:
1: reg1 ← MEM[base+p]
2: regd ← reg1
3: reg1 ← reg1+stride
4: MEM[base+p] ← reg1
...
9: MEM[regd] ← MEM[regs]
Mem[base+p]
1 3
reg1
reg1
2 4
regd
9 Mem[base+p]
Mem[regd]
Finding Buffer Overflow Inducing Loops in Binary Executables 18/26](https://image.slidesharecdn.com/main-130102041321-phpapp01/85/Buffer-Overflow-Prone-Function-Detection-20-320.jpg)
Buffer Overflow Prone Function Detection
- 1. Finding Buffer Overflow Inducing Loops in Binary Executables Sanjay Rawat, Laurent Mounier VERIMAG University of Grenoble, France SERE 2012 Finding Buffer Overflow Inducing Loops in Binary Executables 1/26
- 2. Outline 1 Motivation: software vulnerability analysis 2 Identifying Buffer-overflow Inducing Loops 3 Implementation and experimental results 4 Conclusion and perspectives Finding Buffer Overflow Inducing Loops in Binary Executables 2/26
- 3. Software Vulnerability “A software flaw that may become a security threat . . . ” Examples: memory safety violation (buffer overflow, dangling pointer, etc.) arithmetic overflow unchecked input data race condition, etc. Possible consequences: denial of service (program crash) code injection priviledge escalation, etc. Finding Buffer Overflow Inducing Loops in Binary Executables 3/26
- 4. Software vulnerability detection Hand based analysis: (with some limited tool assistance, e.g. disassemblers, debuggers) conducted by security experts based on known security holes and/or security patches Static analysis: abstract interpretation, symbolic execution ex: memory safety violations (buf. overflows) operate mostly at the source level over-approximations large number of false positives . . . Runtime analysis: security testing, fuzzing execute the program with specific inputs (random mutations, bad string formats, etc.) may cover only a small part of the application code . . . Finding Buffer Overflow Inducing Loops in Binary Executables 4/26
- 5. Software vulnerability detection Hand based analysis: (with some limited tool assistance, e.g. disassemblers, debuggers) conducted by security experts based on known security holes and/or security patches Static analysis: abstract interpretation, symbolic execution ex: memory safety violations (buf. overflows) operate mostly at the source level over-approximations large number of false positives . . . Runtime analysis: security testing, fuzzing execute the program with specific inputs (random mutations, bad string formats, etc.) may cover only a small part of the application code . . . Finding Buffer Overflow Inducing Loops in Binary Executables 4/26
- 6. Software vulnerability detection Hand based analysis: (with some limited tool assistance, e.g. disassemblers, debuggers) conducted by security experts based on known security holes and/or security patches Static analysis: abstract interpretation, symbolic execution ex: memory safety violations (buf. overflows) operate mostly at the source level over-approximations large number of false positives . . . Runtime analysis: security testing, fuzzing execute the program with specific inputs (random mutations, bad string formats, etc.) may cover only a small part of the application code . . . Finding Buffer Overflow Inducing Loops in Binary Executables 4/26
- 7. A current trend: smart fuzzing • A combination between static and runtime analysis • Several approaches, e.g.: Concolic (aka dynamic/symbolic) execution: symbolic execution of concrete paths coverage-oriented (explore uncovered execution paths) Statically directed runtime analysis use static analysis techniques to identify “vulnerable” execution paths use test based techniques to explore them at runtime Finding Buffer Overflow Inducing Loops in Binary Executables 5/26
- 8. Vulnerability Patterns How to find a needle in a haystack ? A common starting point to all analysis techniques: → identify a (small) subset of “potentially vulnerable” functions . . . ⇒ vulnerability patterns Existing solutions: unsafe library functions (strcpy, memcpy, printf, etc) previously known vulnerable functions (smart) code coverage techniques (e.g. Sage) Finding Buffer Overflow Inducing Loops in Binary Executables 6/26
- 9. Work objective → Define and identify semantic vulnerability patterns ... should be easy to compute only lightweight analysis are affordable at the whole pgm level should be discriminating enough ... to give a precise pgm slice and then to conduct deeper analysis ... but not too much ! to avoid false negatives We focus here on Buffer Overflow vulnerabilities (ranked 3 in last “Top 25 Most Dangerous Software Errors1 ”) 1 http://cwe.mitre.org/top25/ Finding Buffer Overflow Inducing Loops in Binary Executables 7/26
- 10. Concrete examples Three recent stack-based buffer overflow vulnerabilities: FreeType font library used by Mozilla products (CVE-2012-1144 and CVE-2012-1141) Adobe Flash Player: (CVE-2012-2035, under review) Caused by dedicated buffer copy functions (= strcpy, etc.) . . . → There may exist many similar functions (sleeping bombs!) ⇒ Requires a specific behavioral vulnerability pattern: Buffer-Overflow Inducing Loops (BOILs) Finding Buffer Overflow Inducing Loops in Binary Executables 8/26
- 11. Outline 1 Motivation: software vulnerability analysis 2 Identifying Buffer-overflow Inducing Loops 3 Implementation and experimental results 4 Conclusion and perspectives Finding Buffer Overflow Inducing Loops in Binary Executables 9/26
- 12. Motivating example 1 char * bufCopy ( char * destination , char * source ) { 2 char * p = destination ; 3 while (* source != ’ 0 ’) 4 { 5 * p ++ = * source ++; 6 } 7 * p = ’ 0 ’; 8 return destination ; 9 } Listing 1: Example of a function that is similar to strcpy There is a loop, iterating over source and destination. Memory which is being read/written is changing within the loop. Finding Buffer Overflow Inducing Loops in Binary Executables 10/26
- 13. BOILs and BOPs BOIL A loop is a BOIL if 1 there is a Memory Write within the loop 2 the written address is changing within the loop (→ write into a destination buffer) 3 the written value depends on a function argument (→ write a possibly tainted value) Additionally the number of iterations should not be fixed, and not depending on the destination buffer . . . BOP A function is Buffer-Overflow Prone (BOP) if it contains a BOIL. Finding Buffer Overflow Inducing Loops in Binary Executables 11/26
- 14. Identifying BOILs ? A lightweight decision procedure operating on binary code: 1 Loop detection → classical algorithms based on dominator tree computations 2 A Memory Write inside the loop → “store” instruction recognition 3 Written address is changing within the loop → ∃ a self def-use dependency chain 4 Written value depends on function argument → ∃ a def-use dependency chain Finding Buffer Overflow Inducing Loops in Binary Executables 12/26
- 15. Example 1: function strcpy Assembly code of strcpy → Within the loop, memory is accessed via registers → Dependency on argument & local variable not visible inside the loop Memory is written once: change of memory address = incrementing registers Finding Buffer Overflow Inducing Loops in Binary Executables 13/26
- 16. Example 2: function bufCopy Assembly code of bufCopy → Dependency on argument/local variable visible inside the loop Memory is written 3 times: to change the stored address of the next character to store the character itself Finding Buffer Overflow Inducing Loops in Binary Executables 14/26
- 17. Characterizing the code patterns (1) Strided memory access pattern within a loop Pattern A (strcpy function, rather straightforward) 1: regd ← MEM[base+dest] DEST adr. 2: regs ← MEM[base+src] SRC adr. loop 3: MEM[regd] ← MEM[regs] copy SRC to DEST 4: regd ← regd+stride 5: regs ← regs+stride endloop Finding Buffer Overflow Inducing Loops in Binary Executables 15/26
- 18. Characterizing the code patterns (2) pattern B (bufCopy function, less straightforward): MEM[base+p] ← MEM[base+dest] DEST adr. loop 1: reg1 ← MEM[base+p] 2: regd ← reg1 3: reg1 ← reg1+stride 4: MEM[base+p] ← reg1 next DEST adr. 5: reg2 ← MEM[base+src] SRC adr 6: regs ← reg2 7: reg2 ← reg2+stride 8: MEM[base+src] ← reg2 next SRC adr. 9: MEM[regd] ← MEM[regs] copy SRC to DEST endloop Finding Buffer Overflow Inducing Loops in Binary Executables 16/26
- 19. Self def-use dependency chains def-use dependency chain Sequence of the type: v1 → v2 → v3 → . . . → vk vi = register, variable or argument vi is defined in terms of vi+1 (vi := ...vi+1 ...) self def-use dependency: ⇒ a simple data-flow analysis (reaching definitions) . . . Finding Buffer Overflow Inducing Loops in Binary Executables 17/26
- 20. Example on pattern B code for pattern B: 1: reg1 ← MEM[base+p] 2: regd ← reg1 3: reg1 ← reg1+stride 4: MEM[base+p] ← reg1 ... 9: MEM[regd] ← MEM[regs] Mem[base+p] 1 3 reg1 reg1 2 4 regd 9 Mem[base+p] Mem[regd] Finding Buffer Overflow Inducing Loops in Binary Executables 18/26
- 21. Extension Check if iteration condition depends on the destination buffer ? A simple heuristic: 1 find the loop controlling variables (look for comparison inst. before cond. jumps) 2 compute its def-use dependency chain → should reach a variable or argument 3 check if this argument is the dest buffers → if yes, assume it is not a vulnerable loop Remark: May be too strict, possible false negatives . . . Finding Buffer Overflow Inducing Loops in Binary Executables 19/26
- 22. Outline 1 Motivation: software vulnerability analysis 2 Identifying Buffer-overflow Inducing Loops 3 Implementation and experimental results 4 Conclusion and perspectives Finding Buffer Overflow Inducing Loops in Binary Executables 20/26
- 23. Tool Chain binary code IDAPro x86 BinNavi REIL {suspicious loops} BOIL BinNavi and REIL intermediate language only 17 instructions, very simple addressing mode; powerful jython API; CFG construction and analysis; MonoREIL: execution engine for data-flow analysis Finding Buffer Overflow Inducing Loops in Binary Executables 21/26
- 24. Experimentations Objectives Evaluate the relevance of the BOIL criterion: percentage of “vulnerable functions” detected ? do they contain real vulnerabilities ? scalability of the analysis ? Methodology → include known vulnerable applications/libraries in the benchmark Finding Buffer Overflow Inducing Loops in Binary Executables 22/26
- 25. Experimental Results Module # func # loops BOILs BOP func FreeFloat FTP 309 146 21 (14%) 12 (3%) CoolPlayer 995 1036 156 (15%) 56 (5%) GDI32.dll 1775 655 70 (10%) 51 (3%) freeType 1910 2568 409 (15%) 249 (13%) msvcr80.dll 2321 1154 188 (16%) 113 (4%) Execution times = a few minutes . . . Remarks freeType: recognized t42 parse sfnts function (array index error) CVE-2010-2806, CVE-2012-1144 and CVE-2012-1141 (Mozilla) GDI32.dll: recognized strcpy-like functions (StringCchCopy) FreeFloat FTP/CoolPlayer: recognized strcpy, wcscpy functions responsible for BoF. OSVDB: 69621. Finding Buffer Overflow Inducing Loops in Binary Executables 23/26
- 26. Outline 1 Motivation: software vulnerability analysis 2 Identifying Buffer-overflow Inducing Loops 3 Implementation and experimental results 4 Conclusion and perspectives Finding Buffer Overflow Inducing Loops in Binary Executables 24/26
- 27. Conclusion Vulnerability detection methods driven by vulnerability patterns These patterns needs to be: easy to compute (scalability) discriminating enough (reduced slice) We proposed a BOIL criterion for BoF vulnerabilities Experimental results are good: flags ∼ 10% of loops as “suspicious” allows to retrieve existing vulnerabilities Finding Buffer Overflow Inducing Loops in Binary Executables 25/26
- 28. Future Work Integration within a complete vulnerability analysis framework: static binary code BOIL code slice taint analysis path−oriented vulnerable paths Fuzzing ... input generation + input offsets Similar approaches for other kinds of vulnerabilities: e.g., use-after-free Finding Buffer Overflow Inducing Loops in Binary Executables 26/26