Bouncersecuring 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

conditionsconditionstrace

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:

1 1 1 097 97 97 97

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: b0,…

• 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

mov p0, al

L: mov eax, msg

movsx eax, [eax+1]

cmp eax, 0

jle M

mov p1, al

M:

symbolic state*msg b0,b1,…

eax (movsx b0)

eflags (cmp (movsx b0) 0)

p0 b0

path conditions(jg (cmp (movsx b0) 0)) [b0 > 0]

Example symbolic execution

mov eax, msg

movsx eax, [eax]

cmp eax, 0

jle L

mov p0, al

L: mov eax, msg

movsx eax, [eax+1]

cmp eax, 0

jle M

mov p1, al

M:

symbolic state*msg b0,b1,…

eflags (cmp (movsx b0) 0)

p0 b0

path conditions(jg (cmp (movsx b0) 0)) [b0 > 0]

eax (movsx b1)

Example symbolic execution

mov eax, msg

movsx eax, [eax]

cmp eax, 0

jle L

mov p0, al

L: mov eax, msg

movsx eax, [eax+1]

cmp eax, 0

jle M

mov p1, al

M:

symbolic state*msg b0,b1,…

eflags (cmp (movsx b1) 0)

p0 b0

path conditions(jg (cmp (movsx b0) 0)) [b0 > 0]

eax (movsx b1)

and (jg (cmp (movsx b1) 0)) [b1 > 0]

Properties of path conditions

• path conditions can filter with no false positivesb0 > 0 Λ b1 > 0 Λ b2 = 1 Λ b1503 = 0 Λ bi ≠ 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 b0 ≤ 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 – bi ≠ 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

1 mov eax, msg 2 movsx eax, [eax+1]3 cmp eax, 0 4 jle 6 5 mov p1, al 6 mov eax, msg7 movsx eax, [eax+2]8 cmp eax, 19 jne Na movsx eax, p0b mov ecx, msgc add ecx, 3d push eax # call sprintfe push ecx

dependenciesmsg[3], msg[4], msg[5],…,ecx

slice…,e,d,c

msg

,b,9

,eflags

,8

,eax

,7

,msg[2],msg[2]

,6

Example filter after each phase

• after symbolic executionb0 > 0 Λ b1 > 0 Λ b2 = 1 Λ b1503 = 0

Λ bi ≠ 0 for all 2 < i < 1503

• after symbolic summaryb0 > 0 Λ b1 > 0 Λ b2 = 1 Λ bi ≠ 0 for all 2 < i < 1016

• after slicingb2 = 1 Λ bi ≠ 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

service false positives false negatives

SQL server no no

ghttpd no yes

nullhttpd no yes

stunnel no no

• bouncer filters have no false positives• perfect filters for two vulnerabilities

Conditions after each phase

Filter generation time

Throughput with filters

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