Static analysis for exploitable vulnerability detection Marie-Laure Potet VERIMAG University of Grenoble September 2014 Static analysis for exploitable vulnerability detection 1/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 2/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 3/43
The present “A software flaw that may become a security threat . . . ” invalid memory access (e.g., buffer overflows, dangling pointers) , arithmetic overflow, race conditions, etc. Still present in current applications and OS kernels: 5000 in 2011, 5200 in 2012, 6700 in 2013 . . . [Symantec] Multiple consequences: program crash, malware injection, priviledge escalation, etc. A business A market has been established for vulnerabilities Companies, governments and criminals buy vulnerability information and accompanying exploits Up to $250,000 for a single zero - day exploit Static analysis for exploitable vulnerability detection 4/43
Practice in terms of vulnerability analysis 1 Identification of flaws dangerous patterns, fuzzing and crashes identification . . . 2 Possibility of exploit (exploitability) poc elaboration, taint analysis, crash analysis . . . 3 Building an real exploit hijacking countermeasures (sandboxing, DEP, ASLR) using well-established techniques and forms of shellcodes Current practice : fuzzing + manual crash analysis ⇒ Challenges : classification of flaws that are exploitable, false positive/negative, real exploits (dedicated expertise) Static analysis for exploitable vulnerability detection 5/43
Example 1 1 void bufCopy(char *dst , char *src) 2 { 3 char *p = dst; 4 while (*src != ’\0’) *p++ = *src ++; 5 *p = ’\0’; 6 } 1 void CallbufCopy(char *src) 2 {char dst [4] ; 3 bufCopy(dst , src); 4 } 1 Flaw: buffer overflow if no 0 in the first four characters 2 Poc : control flow hijacking if the return address is erased 3 Weaponized exploit : DEP ( → ROP), ASLR ( → address leaking, unrandomized library . . . ) Sandboxing ( → own vulnerability) Static analysis for exploitable vulnerability detection 6/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 7/43
Used Static analysis technics Static analysis : all traces can be taken into account (or a significant part of), possibility of symbolic reasoning Technics we use: Taint and dependency analysis impact of inputs, data and control dependencies Value analysis Determine set of values including reachable values (abstract interpretation) Symbolic execution (or concolic) Build path predicates and resolve them by SMT solvers. Example 1 with size(dst)=4 and size(src)=8: p0 = dst0 and not(*src0=’\0’) and *p0=*src0 and p1=p0+1 and src1=src0+1 and not(*src1=’\0’) and *p1=*src1 and p2=p1+1 and src2=src1+1 and *src2=’\0’and *p2=’\0’ Pathcrawler/Klee: 9 test cases (4+4+1) Static analysis for exploitable vulnerability detection 8/43
Static analysis and vulnerability detection Applications for vulnerability detection: identification of sensible parts of code (sophisticated patterns involving values) input generation from symbolic paths (slicing) generalization of traces (exploitability) ⇒ Exploitability only makes sense at the binary level Challenges : Taint and dependency analysis require a value analysis bitvector representation and adapted memory models scalability/completeness Static analysis for exploitable vulnerability detection 9/43
Binary level and dependency ⇒ Taint analysis at the source level: 1 int x, *p, y; 2 x = 3 ; 3 p = &x ; 4 y = *p + 4 ; -- y is untainted ⇒ Taint analysis at the assembly level: Assembly Value analysis result /* x=3; */ mov [ebp-4], 3 Mem[ebp-4]=3 lea eax, [ebp-4] eax = ebp-4 /* p = &x ;*/ mov [ebp-8], eax Mem[ebp-8] = ebp-4 mov eax, [ebp-8] eax = Mem[ebp-8] /* y = *p+4 ; */ mov eax, [eax] eax = Mem[Mem[ebp-8]] = Mem[ebp-4] add eax, 4 eax = Mem[ebp-4] + 4 mov [ebp-12], eax Mem[ebp-12] = eax = Mem[ebp-4] + 4 = 3 + 4 Mem[ebp-12] is untainted. Static analysis for exploitable vulnerability detection 10/43
Adapted memory models Verification: detection of undefined behaviors separate regions (stack frames, block allocation, array . . . ) Vulnerability detection: exploitation of undefined behaviors memory layout representation (flat memory) Problems: value analysis : weak update/ strong update Symbolic reasoning : select ( store ( t , i , v ) , i ) = v select ( store ( t , i , v ) , j ) = select ( t , j , v ) if i � = j Static analysis for exploitable vulnerability detection 11/43
Exploitability ⇒ Generalization of a crash adding constraints (PC corruption, writing a determined portion of memory ...).Example (12 loop traversals for rewriting the return address): p0 = dst0 // initialization and not (*src0=’\0’) and *p0=*src0 and p1=p0+1 and src1=src0+1 // ex. 1 ... ... and not(*src8=’\0’) and *p8=*src8 and p9=p8+1 and src9=src8+1 // ex. 9 and not(*src9=’\0’) and *p9=*src9 and p10=p9+1 and src10=src9+1 // ex. 10 and not(*src10=’\0’) and *p10=*src10 and p11=p10+1 and src11=src10+1 // ex. 11 and not(*src11=’\0’) and *p11=*src11 and p12=p11+1 and src12=src11+1 // ex. 13 and *src8=’A’and *src9=’B’and *src10=’C’ and *src11=’D’ // \@ payload and *src12=’\0’ and *p12=’\0’ AEG a new domain (Sean Heelan, David Brumley,BinSec). Challenges: how to generalize? memory models between flat models and fine-grained regions exploitability conditions for other vulnerabilities Static analysis for exploitable vulnerability detection 12/43
Our approach ⇒ Identifying exploitable paths and building appropriate inputs Using static analysis in order to slice interesting behaviours structural patterns and static taint analysis Using static/dynamic analysis for exploitability condition Symbolic exploitability conditions and dependency Using concolic or genetic approach to produce inputs guided fuzzing ⇒ Buffer overflow : SERE11 (BO pattern), SAW’14 (inter-procedural static taint analysis), ECND10, SECTEST11 (fitness functions and mutations) ⇒ Prototype: IdaPro+REIL Static analysis for exploitable vulnerability detection 13/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 14/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 15/43
Use after free : dangling pointer + access 1 2 typedef struct { 3 void (*f)(void); 4 } st; 5 6 void nothing () 7 { 8 printf("Nothing\n"); 9 } 10 11 int main(int argc , char * argv []) 12 { 13 st *p1; 14 char *p2; 15 p1=(st*) malloc(sizeof(st)); 16 p1 ->f=& nothing; 17 free(p1); // p1 freed 18 p2=malloc(strlen(argv [1])); // possible re -allocation 19 strcpy(p2 ,argv [1]); 20 p1 ->f(); // Use 21 return 0; 22 } Static analysis for exploitable vulnerability detection 16/43
Motivations Motivations Use-After-Free more and more frequent (CVE-2014-0322 (internet explorer), CVE-2014-1512 (firefox,thunderbird)) Static approach for finding exploitable vulnerabilities → an adapted modelling of the heap 200 Broswer Number of CVE related to UaF Other 150 100 50 0 2 , 008 2 , 009 2 , 010 2 , 011 2 , 012 2 , 013 Years https://web.nvd.nist.gov/view/vuln/search , 4 june 2013 Static analysis for exploitable vulnerability detection 17/43
State of art Specificity of UaF No easy ” pattern”(like for buffer overflow / string format) Trigger of several dispatched events (alloc/free/use) Strongly depends on the allocation/liberation strategy source level detection tools Binary code On binary code, state of the art focused more on dynamic analysis Fuzzing + custom allocator (AddressSanitizer) Exploit studied after UaF found (Undangle) New Microsoft protections for navigators (separated heaps, safe memory management) (June 2014) Static analysis for exploitable vulnerability detection 18/43
Proposed approach Goal : extract subgraphs of CFG leading to exploitable Use-After-Free Approach 2 steps : Step 1 : Detection of Use-After-Free Value analysis Characterization of Use-After-Free Step 2 : Exploitability of Use-After-Free Determining possible re-allocations Exploitability condition (ongoing work) Semi-automatic : choice of allocation strategy properties Static analysis for exploitable vulnerability detection 19/43
Outline 1 Context Vulnerability detection process Static analysis 2 Use-after-free detection and exploitability Our approach Detection Exploitability Prototype 3 Conclusion Projects Bibliographie Static analysis for exploitable vulnerability detection 20/43
Recommend
More recommend
