Rule-based static analysis of network protocol implementations
Octavian Udrea, Cristian Lumezanu, and Jeffrey S. Foster
Usenix Security Symposium 2006Speaker: Chang Huan Wu
2008/10/29
2
Outline
IntroductionRule-Based Protocol SpecificationAnalysis of Protocol Source CodeExperiment ResultsConclusions
3
Introduction - Motivation
Network protocols must be reliable and secure– Most works focuses on abstract protocols– Implementation can introduce vulnerabilities
Goal: Check that implementations match specifications
4
Introduction - Architecture
5
Rule-Based Protocol Specification A simple protocol
0. int main(void) {1. int sock, val = 1, recval;2. send(sock, &val, sizeof(int));3. while(1) {4. recv(sock, &recval, sizeof(int));5. if (recval == val)6. val += 2;7. send(sock, &val, sizeof(int));8. }9. }
1. Start by sending n = 12. If n is received, send n + 13. Otherwise resend n
6
Rule-Based Protocol Specification Developed rules from specification document
such as an RFC or IETF standard Ex. (2) means “ if recv in, and in equals n, th
en we have to send out, which is in’s value plus 1 , and we change current state by setting n:= out ”
n: ghost variable, representing protocol state
7
Analysis of Protocol Source Code
Construct a control-flow graph (CFG) from the program source code
Each statement forms a node, and there is an edge from s1 to s2 if statement s1 occurs immediately before statement s2
8
Analysis – Rule 1 (1/3)
Ø (empty hypothesis)=> send(_, out, _) out[0..3] = 1 n := 1
Fact: {}(Matches the empty hypothesis)
9
Analysis – Rule 1 (2/3)
Ø (empty hypothesis)=> send(_, out, _) out[0..3] = 1 n := 1
Fact: {val = 1}
10
Analysis – Rule 1 (3/3)
Ø (empty hypothesis)=> send(_, out, _) out[0..3] = 1 n := 1
Fact: {val = 1, out = &val}Show: Fact → (out[0..3] = 1)Action: n := 1
11
Analysis – Rule 3 (1/3) recv(_, in, _) in[0..3] ≠ n=> send(_, out, _) out[0..3] = n
Fact: {val = 1, n = 1, in = &recval, in[0..3] ≠ n}
12
Analysis – Rule 3 (2/3) recv(_, in, _) in[0..3] ≠ n=> send(_, out, _) out[0..3] = n
Fact: {val = 1, n = 1, in = &recval, in[0..3] ≠ n, recval ≠ val}
13
Analysis – Rule 3 (3/3) recv(_, in, _) in[0..3] ≠ n=> send(_, out, _) out[0..3] = n
Fact: {val = 1, n = 1, in = &recval, in[0..3] ≠ n, recval ≠ val, out = &val}
Show: Fact → (out[0..3] = n)
14
Analysis – Rule 2 (1/4) recv(_, in, _) in[0..3] = n=> send(_, out, _) out[0..3] = n
Fact: {val = 1, n = 1, in = &recval, in[0..3] = n}
15
Analysis – Rule 2 (2/4) recv(_, in, _) in[0..3] = n=> send(_, out, _) out[0..3] = n
Fact: {val = 1, n = 1, in = &recval, in[0..3] = n, recval = val}
16
Analysis – Rule 2 (3/4) recv(_, in, _) in[0..3] = n=> send(_, out, _) out[0..3] = n
Fact: {val = 3, n = 1, in = &recval, in[0..3] = n, recval = val}
17
Analysis – Rule 2 (4/4) recv(_, in, _) in[0..3] = n=> send(_, out, _) out[0..3] = n
Fact: {val = 3, n = 1, in = &recval, in[0..3] = n, recval = val, out = &val}
Show: Fact → (out[0..3] = in[0..3] +1) Fail!!!
18
Experiment Results (1/3)
Evaluated Pistachio by analyzing the LSH implementation of SSH2 and the RCP implementation from Cygwin’s package
Chose these systems because of their extensive bug databases and the number of different versions available
19
Experiment Results (2/3) 96 rules for SSH2 58 rules for RCP
20
Experiment Results (3/3) Add some rules that is strongly recommended
but not required by specification 9 new for LSH, 7 new for RCP
21
Sample compatibility bug
Spec: reply to every version
In LSH version 0.2.9
22
Sample functionality bug
Spec: can’t use “none” method
In LSH version 0.1.3
23
Sample buffer overflow
strcpy() is not safe
In LSH version 0.9.1
24
ConclusionDefined a rule-based method for the
specification of network protocols which closely mimics protocol descriptions in RFC or similar documents
Shown how static analysis techniques can be employed in checking protocol implementations against the rule-based specification
25
CommentsIt is important that network
protocols must be reliable and secure
Can only handle rule violationFalse-positive rate is kind of high
Top Related