Bouncer securing software by blocking bad input Miguel Castro Manuel Costa, Lidong Zhou, Lintao Zhang, and Marcus Peinado Microsoft Research

Software is vulnerable bugs are vulnerabilities attackers can exploit vulnerabilities –to crash programs –to gain control over the execution vulnerabilities are routinely exploited we keep finding new vulnerabilities

How we secure software today static analysis to remove vulnerabilities checks to prevent exploits –type-safe languages –unsafe languages with instrumentation but what do you do when a check fails? –(usually) no code to recover from failure –restarting may be the only option bad because programs are left vulnerable to –loss of data and low-cost denial of service attacks

Blocking bad input Bouncer filters check input when it is received filters block bad input before it is processed –example: drop TCP connection with bad message –input is bad if it can exploit a vulnerability most programs can deal with input errors programs keep working under attack –correctly because filters have no false positives –efficiently because filters have low overhead

Outline architecture symbolic execution symbolic summaries precondition slicing evaluation

program instrumented to detect attacks & log inputs program instrumented to detect attacks & generate trace generate filter conditions for sample generation of alternative exploits combine sample conditions conditionstrace filter new exploit sample exploit Bouncer architecture attacks

Example vulnerable code: char buffer[1024]; char p0 = 'A'; char p1 = 0; if (msg[0] > 0) p0 = msg[0]; if (msg[1] > 0) p1 = msg[1]; if (msg[2] == 0x1) { sprintf(buffer, "\\servers\\%s\\%c", msg+3, p0); StartServer(buffer, p1); } sample exploit:

Symbolic execution analyze trace to compute path conditions –execution with any input that satisfies path conditions follows the path in the trace –inputs that satisfy path conditions are exploits execution follows same path as with sample exploit use path conditions as initial filter –no false positives: only block potential exploits

Computing the path conditions start with symbolic values for input bytes: b 0,… perform symbolic execution along the trace keep symbolic state for memory and registers add conditions on symbolic state for: –branches: ensure same outcome –indirect control transfers: ensure same target –load/store to symbolic address: ensure same target

Example symbolic execution mov eax, msg movsx eax, [eax] cmp eax, 0 jle L movp0, al L: mov eax, msg movsx eax, [eax+1] cmpeax, 0 jleM mov p1, al M: symbolic state *msgb 0,b 1,…eax(movsx b 0 )eflags(cmp (movsx b 0 ) 0)p0b0b0 path conditions (jg (cmp (movsx b 0 ) 0)) [b 0 > 0]

Example symbolic execution mov eax, msg movsx eax, [eax] cmp eax, 0 jle L movp0, al L: mov eax, msg movsx eax, [eax+1] cmpeax, 0 jleM mov p1, al M: symbolic state *msgb 0,b 1,…eflags(cmp (movsx b 0 ) 0)p0b0b0 path conditions (jg (cmp (movsx b 0 ) 0)) [b 0 > 0] eax(movsx b 1 )

Example symbolic execution mov eax, msg movsx eax, [eax] cmp eax, 0 jle L movp0, al L: mov eax, msg movsx eax, [eax+1] cmpeax, 0 jleM mov p1, al M: symbolic state *msgb 0,b 1,…eflags(cmp (movsx b 1 ) 0)p0b0b0 path conditions (jg (cmp (movsx b 0 ) 0)) [b 0 > 0] eax(movsx b 1 ) and (jg (cmp (movsx b 1 ) 0)) [b 1 > 0]

Properties of path conditions path conditions can filter with no false positives b 0 > 0 Λ b 1 > 0 Λ b 2 = 1 Λ b 1503 = 0 Λ b i ≠ 0 for all 2 < i < 1503 they catch many exploit variants [Vigilante] but they usually have false negatives: –fail to block exploits that follow different path –example: they will not block exploits with b 0 ≤ 0 –attacker can craft exploits that are not blocked we generalize filters to block more attacks

Symbolic summaries symbolic execution in library functions –adds many conditions –little information to guide analysis to remove them symbolic summaries –use knowledge of library function semantics –replace conditions added during library calls –are generated automatically from a template template is written once for each function summary is computed by analyzing the trace

Example symbolic summary the vulnerability is in the call –sprintf(buffer, "\\servers\\%s\\%c", msg+3, p0) the symbolic summary is –b i ≠ 0 for all 2 < i < 1016 –it constrains the formatted string to fit in buffer –it is expressed as a condition on the input summary is computed by –using concrete and symbolic argument values –traversing trace backwards to find size of buffer

Pre-condition slicing analyze code and trace to compute a path slice: –slice is a subsequence of trace instructions whose execution is sufficient to exploit the vulnerability generalize filter using the slice –keep conditions added by instructions in slice –discard the other conditions –reduces false negative rate –does not introduce false positives

Computing the slice add instruction with the vulnerability to slice traverse trace backwards track dependencies for instructions in slice add instructions to slice when –branches: path from branch may not visit last slice instruction path to last slice instruction can change dependencies –other instructions: can change dependencies combination of static and dynamic analysis

Example char buffer[1024]; char p0 = 'A'; char p1 = 0; if (msg[0] > 0) p0 = msg[0]; if (msg[1] > 0) p1 = msg[1]; if (msg[2] == 0x1) { sprintf(buffer, "\\servers\\%s\\%c", msg+3, p0); StartServer(buffer, p1); }

Slicing example 1mov eax, msg 2movsx eax, [eax+1] 3cmpeax, 0 4jle6 5mov p1, al 6mov eax, msg 7movsx eax, [eax+2] 8cmp eax, 1 9jne N amovsx eax, p0 bmovecx, msg caddecx, 3 dpusheax # call sprintf epush ecx dependencies msg[3], msg[4], msg[5],…, ecx slice …,e,d,c msg,b,9,eflags,8,eax,7,msg[2],6

Example filter after each phase after symbolic execution b 0 > 0 Λ b 1 > 0 Λ b 2 = 1 Λ b 1503 = 0 Λ b i ≠ 0 for all 2 < i < 1503 after symbolic summary b 0 > 0 Λ b 1 > 0 Λ b 2 = 1 Λ b i ≠ 0 for all 2 < i < 1016 after slicing b 2 = 1 Λ b i ≠ 0 for all 2 < i < 1016 the last filter is optimal

Deployment scenarios distributed scenario –instrument production code to detect exploits –run Bouncer locally on each exploit we detect –deploy improved filter after processing an exploit centralized scenario –software vendor runs cluster to compute filters –vendor receives sample exploits from customers –run Bouncer iterations in parallel in the cluster

Evaluation implemented Bouncer prototype –detected memory corruption attacks with DFI –generated traces with Nirvana –used Phoenix to implement slicing evaluated Bouncer with four real vulnerabilities –SQL server, ghttpd, nullhttpd, and stunnel –started from sample exploit described in literature –ran iterations with search for alternative exploits –single machine; max experiment duration: 24h

Filter accuracy servicefalse positivesfalse negatives SQL serverno ghttpdnoyes nullhttpdnoyes stunnelno bouncer filters have no false positives perfect filters for two vulnerabilities

Conditions after each phase

Filter generation time

Throughput with filters

50 Mbits/sec

Conclusion filters block bad input before it is processed Bouncer filters have –low overhead –no false positives –no false negatives for some vulnerabilities programs keep running under attack a lot left to do