1 / 28

Security Checking

Security Checking. Wishnu Prasetya wishnu@cs.uu.nl www.cs.uu.nl/docs/vakken/pv. Plan. Extended static checking Credential model Security testing Exception. Extended Static Checking (ESC). if nothing else known, then true as pre- cond.

zach
Download Presentation

Security Checking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Checking Wishnu Prasetya wishnu@cs.uu.nl www.cs.uu.nl/docs/vakken/pv

  2. Plan • Extended static checking • Credential model • Security testing • Exception

  3. Extended Static Checking (ESC) if nothing else known, then true as pre-cond • To check some generic correctness properties, e.g. that the program won’t crash due to division by zero, access to an array with an illegal index, null dereference, etc. • Rely on auto-annotation. tax(rate, income | tax) { if(income  10000) tax := 0 ; if (income  20000) tax := income / rate.low ; tax := tax + income / rate.high ; } assertrate.low 0 assertrate.high 0 { true }

  4. Some notes on ESC • We still have to deal with loops • For automation, you may favor the whilek approach, but this approach is not sound. • There may be some crashes that we won’t be able to detect. • Is this bad?

  5. Security • Security: access to certain variables or methods may require certain credentials. • Privacy : an object may have a set of “owners”, and should only be accessed by these owners. • Unifying concept: a credential specifies a set of users. • c  d means that d has at least the same level of access as c. • Example: root , {u}, and  • More abstractly, assume a security domain (C,,), complete lattice.

  6. Expressing security policy in GCL • Global variables cred0 and cred • cred0 can only be assigned once. • cred cred0 should hold, at all time. • Variables can declare the required credentialvar x cydzin ... end • This requirement is static. • Information can only flow towards variables with the same or lower credentials. • Note that not all kinds of security policy can be expressed with these constructs.

  7. Example • Suppose var x cydzin ... • Considercred:=e ; z:=x+yAnnotated to:assert e  cred0 ; cred:=e ; assert c  cred ;assert d  c ; assert d  z:=x+y

  8. Dealing with branches • Consider: if x=0 then x:=y else z:=0 { Q } • After annotation:if x=0 then { assertccred ; x := y } else { assertdcred ; z := 0 } • the wlp :(x=0  (ccred /\ Q[y/x])) /\ (x0  dcred /\ Q[0/z]) • Doubling the formula size  Can we simplify?

  9. Case reduction • (a b) /\ (a  c)  b /\ cReducing wlp like this is sound, but in most cases this is too strong. • There exists an f wheref  ((a b) /\ (a  b)  b /\ c)A realistic f ?

  10. Reducing branch, with security goals • Recall the wlp : (x=0  (ccred /\ Q[y/x])) /\ (x0  dcred /\ Q[0/z]) • Consider dcred as the post-condition. The wlp would then be:(x=0  ccred /\ dcred) /\ (x0  dcred) • Is it reasonable to apply case-reduction on this?

  11. Dealing with loops • [while]k unfolding is too restrictive • An unsound approach in not acceptable. • while y>0 do {x := x+y ; y := y−1} {ccred} • Annotatedto: assert c  cred ; while y > 0 do { assert c  cred ; x := x+y ; assert c  cred ; y := y−1 ; assert c cred ; } W0 = true W1 = (y>0 /\ wlpbody W0) \/ (y0 /\ ccred) = (y>0 /\ ccred) \/ (y0 /\ ccred) = ccred W2 = ... fix point! Nice.

  12. Ok, how about this? • A slightly different post-condition while y > 0 do { assert c  cred ; x := x+y ; assert c  cred ; y := y−1 ; assert c cred ; } W0 = true W1 = (y>0 /\ ccred) \/ (y0 /\ dcred) W2 = (y>1 /\ ccred) \/ (y=1 /\ ccred /\ dcred) \/ (y0 /\ dcred) .... does not terminate  d  cred

  13. You have to fall back... • Need a proposal for an invariant : ccred /\ dcred • Can such a proposal be automated ? while y > 0 do { assert c  cred ; x := x+y ; assert c  cred ; y := y−1 ; assert c cred ; } d  cred

  14. A loop that does something to credentials • while y > 0 do {cred := cred+1 ; y := y−1} { ccred } • Annotated to: W0 = true W1 = (y>0 /\ cred+1cred0 /\ c cred+1) \/ (y0 /\ ccred) = ((y>0 /\ c cred+1) \/ (y0 /\ ccred)) /\ (y>0  cred+1cred0) W2 = ((y>0 /\ c cred+1) \/ (y0 /\ ccred)) /\ (y>1  cred+2cred0) /\ (y=1  cred+1cred0) ... does not terminate  assert c  cred ; while y > 0 do { assert cred+1  cred0 ; cred := cred+1 ; assert c  cred ; y := y−1 ; assert c cred ; }

  15. Need a proposal again... • We can try : cred+y cred0 /\ ccred • Or even: cred+y cred0 /\ ((y>0 /\ c cred+1) \/ (y0 /\ ccred)) assert c  cred ; while y > 0 do { assert cred+1  cred0 ; cred := cred+1 ; assert c  cred ; y := y−1 ; assert c cred ; } { c  cred }

  16. What do we do with loops like the previous one? • Maybe we only have a few • Heuristics to statically analyze the program, and propose invariants • Dynamically infer proposals from logs

  17. Unauthorized use of resource • Represent secured resources as objects, that can only be accessed through their methods. • Programs/Methods can now declare required credential: e  Pr(x | r ) body • Annotate calls to Pr accordingly. • Method’s credential is static; so this is just a simple extension of the scheme we have so far. • How about dynamic binding ?

  18. Input injection attack • Use of external components is security risk. Imagine Pr(x), where x is a user input and inside it sends a query to a backend DB engine. • A program cannot naively trust its user’s input. • Typical approach is to sanitize inputs. query := "SELECT * FROM users” + “WHERE name =’" + userName + "’;" "’ or ’1’=’1"

  19. Modeling sanitation • Introduce function sanitize(expr) • We prefer to treat this function abstractly  uninterpreted function. • But the programmer has to specify, to what credential the result would be appropriate. • syntax: sanitize(expr,c) • It will be the programmer’s responsibility to make sure that the credential claim is met. • our logic will check over the consequences of that.

  20. Examples • y := x+1The resulting wlp will be unsatisfiable the program is definitely not safe  the logic detected it, yay! • y := sanitize(x,c)+1 { cd } • But what if we want to prove this post-cond: cd /\ y=0Losing information due to the taken abstraction...

  21. Dealing with data privacy • Each object o now has a field priv containing the ‘locally’ minimum credential to access the object. • net(o) • priv(o) =  { p.priv | p  net(o) } • Assignment like o.f := 9 is now annotated to:assertpriv(o)cred ; o.f := 9

  22. How about objects restructuring? • How about n.child := o {priv(p)  cred-1 } • Annotated to: assertpriv(n)cred ∧ priv(o)cred ; n.g := o • This wlp ? priv(n)cred ∧ priv(o)cred ∧ priv(p)  cred-1 • But the assignment may potentially affect priv(p) ! • Ok, there are three cases, before the assignment : • p was not in net(o) nor net(n) • p was in net(o) // similary if it was in net(n)

  23. Exception • Exception introduces non-standard flow of execution, which are often error prone; thus also security prone. • The problem is, exception can be thrown from many points in the program, basically exploding the goals to solve for verification. • But first ... how to deal with exception in Hoare logic / wlp ?

  24. Exception • Introduce a global variable exc : bool, initially false • raise sets this variable to true • entering a handler reset it to false • A state where exc is true, is an ‘exceptional’ state, else it is a normal state. • Note that multiple exception types can be encoded. • The obvious:wlpraise Q = Q[true/exc]

  25. Assignments and guards • In GCL evaluating an expression does not crash; so you have to properly ‘annotate’ the expression to model crashes. E.g. : x := a[k]/yshould be transformed to e.g. :if k<0 \/ k#a thenraise ; // alternatively use assert if y=0 thenraise ; // alternatively use assert x := a[k]/y ; • Similar situation with ite and loop guard.s

  26. Sequential composition is now ugly • S1 ; S2 S1; ifexcthen skip else S2 • wlp(S1 ; S2) Q =wlp S1 (exc /\ Q) \/wlp S1 (exc /\ wlp S2 Q) • Now “;” also doubles the formula  • However, you can statically check if S1 contains raise, if it does not, we don’t do the expansion. • while g do S  while g /\ inc do S

  27. exception handler • S ! H  S ; ifexcthen{ exc:=false ; H } else skip • wlp(S ! H) Q =wlp S (exc /\ Q) \/wlp S (exc /\ ((wlp H Q)[false/exc])) • Two scenarios • S manages to terminate normally  H is not executed • S throws an exception  control goes to H

  28. Summary • Static Security Checking can be done, almost automatically. • Require critical variables or classes to declare needed credential • Rely on annotating transformation • Data privacy checking is much harder • Calculating wlp of loops can be challenging, but it looks like it can be mitigated • Branches explode the formula, exception make its even worse; some heuristic to reduce the formula on the fly would be nice; but do watch for the overhead.

More Related