Sparse Representa+on of Implicit Flows with Applica+ons to Side-Channel Detec+on. Bruno Rodrigues Diego Aranha Fernando Pereira

Transcription

1 Sparse Representa+on of Implicit Flows with Applica+ons to Side-Channel Detec+on Bruno Rodrigues Diego Aranha Fernando Pereira

2 Goal The goal of this work is to implement informa+on flow analysis precisely and efficiently in low level languages

3 Goal The goal of this work is to implement informa+on flow analysis precisely and efficiently in low level languages Informa+on flows from variable s to variable d if the value of s determines the value of d. Explicit flows: d = f(..., s,...) Implicit flows: d = s? 0 : 1

4 Contribu+ons The goal of this work is to implement informa+on flow analysis precisely and efficiently in low level languages We avoid worst cases in the technique used by Ferrante et al to build Dependence Graphs. : The program dependence graph and its use in op+miza+on TOPLAS 1987

5 Contribu+ons The goal of this work is to implement informa+on flow analysis precisely and efficiently in low level languages We avoid worst cases in the technique used by Ferrante et al to build Dependence Graphs. We reduce the complexity of implemen+ng Hunt and Sands' System of Security Types. : On flow-sensi+ve security types POPL 2006

6 Contribu+ons The goal of this work is to implement informa+on flow analysis precisely and efficiently in low level languages We avoid worst cases in the technique used by Ferrante et al to build Dependence Graphs. We reduce the complexity of implemen+ng Hunt and Sands' System of Security Types. We have detected security issues in real-world crypto libraries, such as TrueCrypt and OpenSSL.

7 The Challenge Find an efficient way to track implicit flows. int b; if (p) { b = 0; } else { b = 1; } This code contains an implicit flow of informa+on from predicate p to variable b.

8 The Key Idea "The paper proposes an analysis to efficiently discover and represent implicit informa9on flows in programs in sta9c single assignment (SSA) form. It achieves this by focusing on control dependencies from values to values instead of from values to instruc9ons". Sta+c Single Assignment sparse analysis Control dependences from values to values : quo+ng comment from anonymous referee (CC'16)

9 Dependence Graphs Original View Ver+ces are instruc+ons Edge from i 0 to i 1 if i 0 may determine the behavior of i 1 Dependence Graphs Our View Ver+ces are variables in the SSA-form program Edge from v 0 to v 1 if the value of v 0 determines the value of v 1 : The program dependence graph and its use in op+miza+on TOPLAS 1987

10 Example int genkeymask( int seed, l a int* t1, int* t2 ) { uint_64 r; int i = 0; r = random(seed); while (i < 64) { if (r & 1) { t1[i] = 1; } else { t2[i] = 1; } r >>= 1; i++; } } r 0 = random(seed) i 0 = 0 l d l c a 0 = t 1 + i 1 *a 0 = 1 l f p 1 = r 1 & 1 branch p 1 l e l e l b r 2 = r 1 >> 1 i 1 = ϕ(i 0, i 2 ) r 1 = ϕ(r 0, r 2 ) p 0 = (i 1 < 64)? branch p 0 l c a 1 = t 2 + i 1 *a 1 = 1 i 0 i 1 p 0 a 0 p 1 t 1 a 1 i 2 r 2 r 1 r 0 i 2 = i t 2 seed jump l b

11 An Algorithm to Find Implicit Flows datatype Instruction = ASG of string * string list PHI of string list * string list list datatype DomTree = BR of Instruction list * string * DomTree list * DomTree JMP of Instruction list * DomTree list fun link [] _ = [] link _ "" = [] link ((ASG (a, _)) :: insts) lb = (lb, a) :: link insts lb link ((PHI (deflist, _)) :: insts) lb = (map (fn a => (lb, a)) link insts lb fun visit (JMP (instructions, [])) pred = link instructions pred visit (JMP (instructions, [child])) pred = link instructions visit child pred visit (BR (instructions, new_pred, children, ipdom)) pred = let fun visit_every [] = [] visit_every (child::rest) = if child = ipdom then visit child visit_every rest else visit child visit_every rest in link instructions visit_every children end This is our algorithm, in SML/NJ's syntax You do not have to understand it now. But it is premy short And goes down the programs' dominance tree And needs also the program's postdominance tree

12 Important: Dominance a b m n x y Node 'a' dominates node 'b', because any path from to 'b' goes across 'a'. Similarly, node 'b' post-dominates node 'a', because any (backwards) path from to 'a' must go across 'b'. Node n post-dominates node m, but m does not dominate n. Node x dominates node y, but y does not postdominate node x.

13 Stack of Predicates l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 We traverse the dominator tree, "remembering" the predicates that we find on the way. For instance, aper walking on the red path, we will have visited predicates b 0, b 1 and b 2. l 8 : p 0 = v[i] l 9 : len 0 = 0 l 23 : max r [0] = max l 24 : ret sum l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 23 : max r [0] = max l 24 : ret sum l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 19 : max 0 = len l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1 Control flow graph

14 Stack of Predicates l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 We "forget" a predicate p if (i) we are done visi+ng every child of b, the block where p is used in a branch, or (ii) we reach the basic block d that post-dominates b. l 8 : p 0 = v[i] l 9 : len 0 = 0 l 23 : max r [0] = max l 24 : ret sum l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 This block postominates this other block l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 23 : max r [0] = max l 24 : ret sum l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 19 : max 0 = len l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

15 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 stack = [] l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 23 : max r [0] = max l 24 : ret sum We start visi+ng the first basic block, which we shall call b 0-2. At the beginning, we have seen no predicate. This block, b 0-2, terminates with an uncondi+onal jump; hence, we do not have to stack up a new predicate, given that there is none. l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

16 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 stack = [] l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 23 : max r [0] = max l 24 : ret sum We now visit b 3-7, again, with an empty stack. Because the stack is empty, there are no links to create. But this block terminates with a branch br b 0 l 8, l 23. Thus, we push b 0 up. In this way, we will link b 0 to the instruc+ons defined in the children of b 3-7. l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

17 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 stack = [b 0 ] l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 23 : max r [0] = max l 24 : ret sum We are now visi+ng the children of b 3-7. The order in which we visit these children is not important. Both are being visited with the predicate {b 0 }. The important event that will take place soon is the linking of nodes... l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

18 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 stack = [b 0 ] stack = [] l 23 : max r [0] = max l 24 : ret sum We will create implicit flow edges (b 0, p 0 ) and (b 0, len 0 ). However, we will not create the edge (b 0, max r ). This happens because b is the post-dominator of b 3-7, the block where b 0 is defined. When we visit b 23-24, coming out of b 3-7, we pop b 0 before moving further down. l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

19 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 8 : p 0 = v[i] l 9 : len 0 = 0 stack = [b 0 ] l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 stack = [b 1, b 0 ] stack = [b 0 ] l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 23 : max r [0] = max l 24 : ret sum Once we visit b 10_14, there are two things that we must do. First, we must link variables defined there to b 0, which is the current predicate. Second, we must update the current predicate to visit b 15_16. No+ce that this upda+ng happens only to visit b 15_16. We visit b 17_18 with the old predicate {b 0 }, because this block post-dominates b 10_14. l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

20 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 8 : p 0 = v[i] l 9 : len 0 = 0 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 stack = [b 1, b 0 ] stack = [b 0 ] l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 23 : max r [0] = max l 24 : ret sum We link every variable defined at b with b 1, because this is the current predicate once b is visited. From b we are done on this side of the tree, because this block has no children. Once we visit b 17_18 we link every instruc+on in this block to b 0, and not b 1, because b 0 is the current predicate when b 17_18 is visited. We do not have to stack b 1 up to visit b 17_18, because this block post-dominates b 10_14. l 19 : max 0 = len l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

21 l 0 : i 0 = 0 l 1 : sum 0 = 0 l 2 : max 0 = 0 l 8 : p 0 = v[i] l 9 : len 0 = 0 l 3 : i =!(i 0, i 1 ) l 4 : max =!(max 0, max 1 ) l 5 : sum =!(sum 0, sum 1 ) l 6 : b 0 = (i < N)? l 7 : br b 0 l 8, l 23 l 23 : max r [0] = max l 24 : ret sum Aper visi+ng b and b we are done. We link variables in b to b 2, the current predicate, and we link variables in b to b 0, the current predicate when that block is visited. Given that we have no more blocks to visit, we are done! l 11 : len =!(len 0, len 1 ) l 15 : len 1 = len + 1 l 10 : p =!(p 0, p 1 ) l 11 : len =!(len 0, len 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 14 : br b 1 l 15, l 17 l 10 : p =!(p 0, p 1 ) l 12 : t = p[0] l 13 : b 1 = (t!= '\0')? l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 15 : len 1 = len + 1 l 16 : p 1 = p + 1 l 17 : b 2 = (len < max)? l 18 : br b 2 l 19, l 20 l 19 : max 0 = len stack = [b 2, b 0 ] l 19 : max 0 = len stack = [b 0 ] l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1 l 7 : br b 0 l 8, l 23 l 20 : max 1 =!(max 0, max) l 21 : sum 1 = sum + len l 22 : i 1 = i + 1

22 Contribu+ons I We avoid worst cases in the technique used by Ferrante et al to to handle nests of repeat loops and ladder CFGs p v 1 v v v 0 p 3 v 2 v 2 v 3 v 3 p 2 p 2 v 4 v 4 v 5 v 5 p 1 v 6 p 1 v 6 v 7 v 8 v 9 v 10 v 7 v 8 v 9 v 10 Ferrante et al This paper

23 Contribu+ons I We avoid worst cases in the technique used by Ferrante et al to to handle nests of repeat loops (R) and ladder CFGs (L) 900" 800" 700" 600" 500" 400" 300" 200" 100" 0" 5" 6" 7" 8" 9" 10" 11" 12" 13" 14" 15" 16" 17" 18" 19" 20" R+Flow" R+Ferrante" L+Flow" L+Ferrante"

24 Contribu+ons II We reduce the complexity of implemen+ng Hunt and Sands' System of Security Types. l 1 : w = ; l 2 : x = ; l 3 : y = ; l 4 : z = l 5 : p = use(x) l 6 : branch p l 9 l 7 : y = use(y); l 8 : w = use(z) l 9 : p = use(x); l 10 : branch p l exit l 11 : z = use(z, w); l 12 : x = use(z); l 13 : z = use(x) p w x y z 1-2: [, L,,, ] 2-3: [, L, L,, ] 3-4: [, L, L, L, ] 4-5: [, L, L, L, H] 5-6: [L, L, L, L, H] 6-7: [L, L, L, L, H] 7-8: [L, L, L, L, H] 8-9: [L, H, L, L, H] 6-9: [L, L, L, L, H] 9-10: [H, H, H, L, H] 10-11: [H, H, H, L, H] 11-12: [H, H, H, L, H] 12-13: [H, H, H, L, H] 13-9: [H, H, H, L, H]

25 Contribu+ons II We reduce the complexity of implemen+ng Hunt and Sands' System of Security Types. l 1 : w 0 = ; l 2 : x 0 = ; l 3 : y 0 = ; l 4 : z 0 = y 0 l 5 : p 0 = use(x 0 ) l 6 : branch p 0 l 9 y 1 y 2 l 7 : y 1 = use(y 0 ); l 8 : w 1 = use(z 0 ) p 0 x 0 x 1 l 9 : [y 2 = ϕ(y 0, y 1 ); w 2 = ϕ(w 0, w 1 )] w 1 z 0 p 1 l 10 : [x 1 = ϕ(x 0, x 2 ); z 1 = ϕ(z 0, z 3 )] w 2 z 1 z 3 l 11 : p 1 = use(x 1 ); l 12 : branch p 1 l exit l 13 : z 2 = use(z 1, w 2 ); l 14 : x 2 = use(z 2 ); l 15 : z 3 = use(x 2 ) w 0 z 2 x 2

26 Contribu+ons III We have detected security issues in real-world crypto libraries, such as TrueCrypt and OpenSSL. l o w T r a c k e r Making programs safe through static flow analyses Define sources and sinks of informa+on Finds paths between sources and sinks Available on-line at hmp://cuda.dcc.ufmg.br/flowtracker

27 Isochronous Code A program P is isochronous with regard to an input i if P always take the same +me to execute, independent on the value of i. Is this program isochronous with regard to input pw? int foo(char* pw, char* in) {! int i;! for (i = 0; i < 3; i++) {! if (pw[i]!= in[i]) {! return 0;! }! }! return 1;! }!

28 Isochronous Programs A program P is isochronous with regard to an input i if P always take the same +me to execute, independent on the value of i. What about this new program? Is it isochronous with regard to input p? int foo(char* pw, char* in) {! int p0 = pw[0] == in[0];! int p1 = pw[1] == in[1];! int p2 = pw[2] == in[2];! return p0 && p1 && p2;! }!

29 Low-Level Analysis int foo(char* pw, char* in) {! int p0 = pw[0] == in[0];! int p1 = pw[1] == in[1];! int p2 = pw[2] == in[2];! return p0 && p1 && p2;! }! entry: %arrayidx = getelementptr inbounds i8* %pw, i64 0 %tmp = load i8* %arrayidx, align 1 %conv = sext i8 %tmp to i32 %arrayidx1 = getelementptr inbounds i8* %in, i64 0 %tmp1 = load i8* %arrayidx1, align 1 %conv2 = sext i8 %tmp1 to i32 %cmp = icmp eq i32 %conv, %conv2 br i1 %cmp, label %land.lhs.true, label %land.end land.lhs.true: %arrayidx4 = getelementptr inbounds i8* %pw, i64 1 %tmp2 = load i8* %arrayidx4, align 1 %conv5 = sext i8 %tmp2 to i32 %arrayidx6 = getelementptr inbounds i8* %in, i64 1 %tmp3 = load i8* %arrayidx6, align 1 %conv7 = sext i8 %tmp3 to i32 %cmp8 = icmp eq i32 %conv5, %conv7 br i1 %cmp8, label %land.rhs, label %land.end T T F F land.rhs: %arrayidx10 = getelementptr inbounds i8* %pw, i64 2 %tmp4 = load i8* %arrayidx10, align 1 %conv11 = sext i8 %tmp4 to i32 %arrayidx12 = getelementptr inbounds i8* %in, i64 2 %tmp5 = load i8* %arrayidx12, align 1 %conv13 = sext i8 %tmp5 to i32 %cmp14 = icmp eq i32 %conv11, %conv13 br label %land.end land.end: %tmp6 = phi i1 [ false, %land.lhs.true ], [ false, %entry ], [ %cmp14,... %land.rhs ] %land.ext = zext i1 %tmp6 to i32 ret i32 %land.ext

30 Compiling Isochronous Code Compiler writers usually do not worry about preserving the isochronous behavior of code. Yet, current tools that detect +me-based side channels operate at the source code level. We claim that this kind of informa+on flow analysis should be performed at lower levels, for it is the implementa.on, not the abstract design of a crypto algorithm that will be running in produc+on.

31 What FlowTracker does entry: %retval = alloca i32, align 4 %argc.addr = alloca i32, align 4 %argv.addr = alloca i8**, align 8 %sum = alloca i32, align 4 %p = alloca i8*, align 8 %p2 = alloca i8*, align 8 %p14 = alloca i8*, align 8 store i32 0, i32* %retval store i32 %argc, i32* %argc.addr, align 4 store i8** %argv, i8*** %argv.addr, align 8 store i32 0, i32* %sum, align 4 %0 = load i32* %argc.addr, align 4 switch i32 %0, label %sw.epilog [ i32 1, label %sw.bb i32 2, label %sw.bb1 i32 3, label %sw.bb13 ] sw.bb: br label %L0 def sw.bb1: %8 = load i8*** %argv.addr, align 8 %arrayidx3 = getelementptr inbounds i8** %8, i64 0 %9 = load i8** %arrayidx3, align 8 store i8* %9, i8** %p2, align 8 br label %for.cond4 for.cond4: %10 = load i8** %p2, align 8 %cmp5 = icmp ne i8* %10, null br i1 %cmp5, label %for.body7, label %for.end12 for.body7: %11 = load i8** %p2, align 8 %12 = load i8* %11, align 1 %conv8 = sext i8 %12 to i32 %13 = load i32* %sum, align 4 %add9 = add nsw i32 %13, %conv8 store i32 %add9, i32* %sum, align 4 br label %for.inc10 for.inc10: %14 = load i8** %p2, align 8 %incdec.ptr11 = getelementptr inbounds i8* %14, i32 1 store i8* %incdec.ptr11, i8** %p2, align 8 br label %for.cond4 T F for.end12: %15 = load i32* %sum, align 4 %rem = srem i32 %15, 2 %tobool = icmp ne i32 %rem, 0 br i1 %tobool, label %if.then, label %if.else T if.then: br label %L0 F if.else: br label %L1 sw.bb13: br label %L1 FlowTracker points out if secret informa+on controls: The outcome of condi+onal branches The indices of memory addresses L0: %1 = load i8*** %argv.addr, align 8 %arrayidx = getelementptr inbounds i8** %1, i64 0 %2 = load i8** %arrayidx, align 8 store i8* %2, i8** %p, align 8 br label %for.cond L1: %16 = load i8*** %argv.addr, align 8 %arrayidx15 = getelementptr inbounds i8** %16, i64 0 %17 = load i8** %arrayidx15, align 8 store i8* %17, i8** %p14, align 8 br label %for.cond16 for.cond: %3 = load i8** %p, align 8 %cmp = icmp ne i8* %3, null br i1 %cmp, label %for.body, label %for.end for.cond16: %18 = load i8** %p14, align 8 %cmp17 = icmp ne i8* %18, null br i1 %cmp17, label %for.body19, label %for.end24 T F T F for.body: %4 = load i8** %p, align 8 %5 = load i8* %4, align 1 %conv = sext i8 %5 to i32 %6 = load i32* %sum, align 4 %add = add nsw i32 %6, %conv store i32 %add, i32* %sum, align 4 br label %for.inc for.end: br label %sw.epilog for.body19: %19 = load i8** %p14, align 8 %20 = load i8* %19, align 1 %conv20 = sext i8 %20 to i32 %21 = load i32* %sum, align 4 %add21 = add nsw i32 %21, %conv20 store i32 %add21, i32* %sum, align 4 br label %for.inc22 for.end24: br label %sw.epilog for.inc: %7 = load i8** %p, align 8 %incdec.ptr = getelementptr inbounds i8* %7, i32 1 store i8* %incdec.ptr, i8** %p, align 8 br label %for.cond sw.epilog: %23 = load i32* %sum, align 4 ret i32 %23 for.inc22: %22 = load i8** %p14, align 8 %incdec.ptr23 = getelementptr inbounds i8* %22, i32 1 store i8* %incdec.ptr23, i8** %p14, align 8 br label %for.cond16

32 Run+me of FlowTracker 1.E+06' 1.E+05' 1.E+04' 1.E+03' 1.E+02' 0' 1' 2' 3' 4' 5' 6' 7' 8' 9' 10' 11' 12' 13' 14' 15' 16' 17' 18' 19' 20' 21' 22' 23' 24' 25' 26' 27' 28' 29' 30' Number'of'Instruc<ons' Data'Edges' Control'Edges' Time(ms)' Each +ck in the X-axis is a different benchmark. FlowTracker inserts 1,11M control edges in gcc, our largest benchmark, which has 1.25M variables. Behavior is linear (R 2 = 0.98)

33 Generality 100" Address Leak: 52% Buffer Overflow: 53% Integer Overflow: 69% 75" 50" 25" 0" perl" bzip2" mcf" gobmk" hmmer" sjeng" libq" h264" omnet" astar" xalanc" gcc" Address"Leak" Tainted"Flow" Integer"Overflow" Address leak: can an adversary infer the value of a pointer? Buffer overflow: can an adversary control the size of allocated memory, or indices of arrays? Integer Overflow: is there memory indexed by arithme+c opera+ons that may overflow?

34 Issues in Real-World Code We have applied FlowTracker on GLS254. Four warnings. Issues discovered by FlowTracker: A +ming-variant branch which depended on secret informa+on flow but in prac+ce was never taken. The fix involved removing the branch altogether. Variable-+me code that was not called anywhere but was s+ll pointed out. The fix was dele+ng the affected code. No issue found in NaCl : Ellip+c-curve Diffie-Hellman secret sharing using GLS binary curve (L^2 + LZ + az^2)x^2 = X^4 + bz^4 defined over GF(2^254) and implemented with lambda-projec+ve coordinates (X, L, Z).

35

36

37 Conclusion Sparse implementa+on of informa+on flows Track flow between values, not between instruc+ons Web: Video tutorial: Bruno Rodrigues - brunors172@gmail.com! Diego Aranha - dfaranha@gmail.com! Fernando Pereira - fernando@dcc.ufmg.br (that's me!) We are looking for use-cases, and will be happy to help people to understand and use our tool