Rule-based static analysis of network protocol implementations Octavian Udrea, Cristian Lumezanu, and Jeffrey S. Foster Usenix Security Symposium 2006 Speaker: Chang Huan Wu 2008/10/29

2 Outline Introduction Rule-Based Protocol Specification Analysis of Protocol Source Code Experiment Results Conclusions

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 = 1 2. If n is received, send n 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, then 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 s 1 to s 2 if statement s 1 occurs immediately before statement s 2

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 Conclusion Defined 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 Comments It is important that network protocols must be reliable and secure Can only handle rule violation False-positive rate is kind of high