In vfprintf(), if (fmt points to “%n”) then **ap = (character count) Achieving Trusted Systems by Providing Security and Reliability FORMAL REASONING ON SECURITY VULNERABILITIES USING POINTER TAINTEDNESS SEMANTICS Shuo Chen, Karthik Pattabiraman, Zbigniew Kalbarczyk and Ravishankar K. Iyer Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign Motivations Develop methods to enable uncovering of and reasoning about security vulnerabilities in applications. Analysis of vulnerability reports in Bugtraq and CERT advisories indicates that: –Many vulnerabilities due to pointer taintedness: user input value used as a pointer value. –A significant portion of vulnerabilities due to errors in incorrect invocations of library functions Formal Reasoning on Security Vulnerabilities using Pointer Taintedness Semantics Extraction of Security Specifications of Library Functions Pointer Taintedness Caused Vulnerabilities Example of Format String Vulnerability Taintedness Semantics Example: Formal Extraction of Security Specifications of strcpy() Specs Suggested by Theorem ProverFuture Directions Following these findings, developed a formal reasoning method to examine possibility of pointer taintedness in application source code. Pointer Taintedness: a pointer value (including a return address) is derived directly or indirectly from user input. A unifying perspective for reasoning about security vulnerabilities: a root cause of many vulnerabilities. The semantics of pointer taintedness can be formally defined. The notion of pointer taintedness enables: –Static analysis: reasoning about the possibility of pointer taintedness by source code analysis; –Runtime checking: inserting assertions in object code to check pointer taintedness at runtime; –Architecture-based checking: enhancing processors to detect pointer taintedness. Current focus: extraction of security specifications of library functions based on pointer taintedness semantics. A formal approach to reason about potential vulnerabilities in library source code. Reasoning based on a hypothetical memory model: a boolean property taintedness associated with each memory location. The semantics of pointer taintedness defined in equational logic. A theorem prover employed to extract security specifications of library functions. Security specifications extracted by the analysis: –expose classes of known security vulnerabilities, such as format string, heap corruption and buffer overflow vulnerabilities; –indicate the possibility of function invocation scenarios that may expose new vulnerabilities. Format string vulnerability –Taint a pointer argument of printf(). Stack smashing –Taint a return address. Heap corruption –Taint the free-chunk doubly-linked list of the heap. Glibc globbing vulnerabilities –User input resides in a location that is used as a pointer by the parent function of glob(). Vulnerable code: recv(buf); printf(buf); \xdd \xcc \xbb \xaa %d %d %d ‘1’ ‘2’ ‘3’ ‘4’ ‘5’ %n %n “12345” %d 0xaabbccdd fmt: format string pointer ap: argument pointer High Low Stack growth *ap is a tainted value. Store represents a snapshot of the memory state at a point in the program execution. Operations on memory locations: –The fetch operation Ftch(S,A) gives the content of the memory address A in store S –The location-taintedness operation LocT(S,A) gives the taintedness of the location A in store S Operations on expressions: –Evaluation operation Eval(S,E) evaluates expression E in store S –Expression-taintedness operation ExpT(S,E) computes the taintedness of expression E in store S –E.g., ExpT(S,^ foo + ^ bar) = … = LocT(S, foo) or LocT(S, bar) char * strcpy (char * dst, char * src) { char * res; 0: res =dst; while (*src!=0) { 1: *dst=*src; dst++; src++; } 2: *dst=0; return res; } 0: mov [res] <- ^ dst lbl(#while#6) branch (^ ^ src is 0) #ex#while#6 1: mov [^ dst] <- ^ ^ src mov [dst] <- (^ dst) + 1 mov [src] <- (^ src) + 1 branch true #while#6 lbl(#ex#while#6) 2: mov [^ dst] <- 0 mov [ret] <- ^ res Translate to Language L a) Suppose S1 is the store before Line L1, then LocT(S1,dst) = false b) If S0 is the store before Line L0, and S2 is the store after Line L1, then I LocT(S2,I) = LocT(S0, I) c) Suppose S3 is the store before Line L1, then LocT(S3,dst) = false Generate theorems based on taintedness semantics Theorem Proving Suppose when function strcpy() is called, the size of destination buffer (dst) is dstsize, the length of user input string (src) is srclen Specifications that are extracted by the theorem proving approach –srclen <= dstsize –The buffers src and dst do not overlap in such a way that the buffer dst covers the NULL-terminator of the src string. –The buffers dst and src do not cover the function frame of strcpy. –Initially, dst is not tainted Documented in Linux man page Not documented Develop a VCGen (verification condition generator) to facilitate theorem proving (based on program annotations). Apply the pointer taintedness analysis to a substantial number of commonly used library functions to extract their security specifications. Compiler techniques for generating “guarding code” to provide security for programs. Architecture supports for pointer taintedness detection. A module working with RSE (Reliability and Security Engine).