Module: Future of Secure Programming

Transcription

1 Module: Future of Secure Programming Professor Trent Jaeger Penn State University Systems and Internet Infrastructure Security Laboratory (SIIS) 1

2 Programmer s Little Survey Problem What does program for security mean? Implement a program Have you ever programmed for security? Without creating vulnerabilities When What is do a vulnerability? you start to consider security when you program? What do you try to do to make your code secure? When do you know you are done making your code secure? Should a programmer fix every flaw in their programs? Systems and and Internet Infrastructure Security Security (SIIS) (SIIS) Laboratory Laboratory 22

3 Programmer s Problem Implement a program Without creating vulnerabilities What is a vulnerability? Systems and Internet Infrastructure Security (SIIS) Laboratory 3

4 Software Vulnerabilities Vulnerability combines A flaw Accessible to an adversary Who can exploit that flaw Which would you focus on to prevent vulnerabilities? Systems and Internet Infrastructure Security Laboratory (SIIS) 4

5 Buffer Overflow Detection For C code where char dest[len]; int n;... n = input();... strncpy(dest, src, n); Can this code cause a buffer overflow? Systems and Internet Infrastructure Security Laboratory (SIIS) 5

6 Runtime Analysis One approach is to run the program to determine how it behaves Analysis Inputs Input Values - command line arguments Environment - state of file system, environment variables, etc. Question Can any input value in any environment cause a vulnerability (e.g., exploit a buffer overflow)? What are limitations of runtime analysis? Systems and Internet Infrastructure Security Laboratory (SIIS) 6

7 Fuzz Testing Dynamic software testing technique Run the software Where invalid, unlikely, and/or random inputs are provided to the program See what happens To detect crashes, exceptions, etc. Which may be indicate of flaws that can be exploited How would this detect a buffer overflow? Fuzz testing is black-box testing do not need to examine the program code to run Research in grey/white-box testing, but industry uses fuzzing Systems and Internet Infrastructure Security Laboratory (SIIS) 7

8 Runtime Static Analysis Analysis One approach is to run the program to determine how it behaves Explore all possible executions of a program! Analysis Inputs All possible inputs! Input Values - command line arguments All possible states! Environment - state of file system, environment variables, etc. Question Can any input value in any environment cause a flaw (e.g., buffer overflow)? What are limitations of runtime analysis? Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 8 8

9 Runtime Static Analysis Provides an approximation of behavior! One approach is to run the program to determine how it behaves Analysis Inputs Run in the aggregate! Input Values - command line arguments Rather than executing on ordinary states! Environment - state of file system, environment variables, etc. Finite-sized descriptors representing a collection of states! Question Run in non-standard way! Can any input value in any environment cause a flaw (e.g., buffer overflow)? Run in fragments! What are limitations of runtime analysis? Stitch them together to cover all paths! Runtime testing is inherently incomplete, but static analysis can cover all paths! Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 10 9

10 Runtime Static Analysis Example Descriptors represent the sign of a value! One approach is to run the program to determine how it behaves Analysis Inputs Positive, negative, zero, unknown! Input Values - command line arguments For an expression, c = a * b! Environment - state of file system, environment variables, etc. If a has a descriptor pos! Question And b has a descriptor neg! Can any input value in any environment cause a flaw (e.g., buffer overflow)? What is the descriptor for c after that instruction?! What are limitations of runtime analysis? How might this help?! Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 11 10

11 Runtime Descriptors Analysis Choose a set of descriptors that! One approach is to run the program to determine how it behaves Analysis Abstracts Inputsaway details to make analysis tractable! Input Preserves Values enough - command information line arguments that key properties hold! Environment - state of file system, environment variables, etc. Can determine interesting results! Question Using sign as a descriptor! Can any input value in any environment cause a flaw (e.g., buffer overflow)? Abstracts away specific integer values (billions to four)! What Guarantees are limitations when of a*b runtime = 0 it analysis? will be zero in all executions! Choosing descriptors is one key step in static analysis! Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 12 11

12 Buffer Overflow Static Analysis For C code where char dest[len]; int n; n = input(); strncpy(dest, src, n); Static analysis will try all paths of the program that impact variable n and flow to strncpy May be complex in general because Paths: Exponential number of program paths Interprocedural: n may be assigned in another function Aliasing: n s memory may be accessed from many places What descriptor values do you care about for n? Systems and Internet Infrastructure Security Laboratory (SIIS) 12

13 Limitations of Static Analysis Scalability Can be expensive to reason about all executions of complex programs False positives Overapproximation means that executions that are not really possible may be found Accuracy Alias analysis and other imprecision may lead to false negatives Sound methods (no false negatives) can exacerbate scalability and false positives problems Bottom line: Static analysis often must be directed Systems and Internet Infrastructure Security Laboratory (SIIS) 13

14 Preventing These Vulnerabilities What can the programmer do to secure their program in such cases? Systems and Internet Infrastructure Security Laboratory (SIIS) 14

15 Information Denning s Lattice Flow Model Control Formalizes information flow models! What is it? FM = {N, P, SC, /, >} Simple security & -property Shows that the information flow model instances form a lattice! N are objects, P are processes,! {SC, >} is a partial ordered set,! SC, the set of security classes is finite,! SC has a lower bound,! and / is a lub operator! Implicit and explicit information flows! Semantics for verifying that a configuration is secure! Static and dynamic binding considered! Biba and BLP are among the simplest models of this type Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 15

16 Implicit and explicit flows Information Flow Control Explicit! What is it? Direct transfer to b from a (e.g., b = a)! Simple security & -property Implicit! Where value of b may depend on value of a indirectly (e.g., if a = 0, then b = c)! Model covers all programs! Statement S! Sequence S1, S2! Conditional c: S1,, Sm! Implicit flows only occur in conditionals! Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 16

17 Information Semantics Flow Control Program What is it? is secure if:! Simple Explicit security flow from & -property S is secure! Explicit flow of all statements in a sequence are secure (e.g., S1; S2)! Conditional c: S1,, Sm is secure if:! The explicit flows of all statements S1,, Sm are secure! The implicit flows between c and the objects in Si are secure! Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 17

18 Build on Type Safety A type-safe language maintains the semantics of types. E.g., can t add int s to Object s. Type-safety is compositional. A function promises to maintain type safety. Systems and Internet Infrastructure Security Laboratory (SIIS) Example 1 Object obj; int i; obj = obj X+ i; Example 2 String proc_obj(object o);... main() { Object obj; String s = proc_obj(obj);... } 18

19 Labeling Types Example 1 int{high} h1,h2; int{low} l; l = 5; h2 = l; h1 = h2 + 10; l = h2 + l; X Key insight: label types with security levels Security-typing is compositional Example 2 String{low} proc_obj(object{high} o);... main() { Object{high} obj; String{low} s; s = proc_obj(obj);... } Systems and Internet Infrastructure Security Laboratory (SIIS) 19

20 Implicit Flows Static (virtual) tagging int Low mydata = 0; int Low mydata2 = 0; if (test High ) mydata = 1; else mydata = 2; mydata2 = 0; print Low (mydata2); print Low (mydata); Systems and Internet Infrastructure Security Laboratory (SIIS) mydata contains information about test so it can no longer be Low,but mydata2 is outside the conditional, so it is untainted by test Causes type error at compile-time 20

21 Retrofitting for Security Take the code written in a language of the programmers choice (for functionality) and retrofit with security code (mostly-automated) Consider authorization bypass vulnerabilities In these vulnerabilities, programmers forget to add code to control access to program resources!! What!is!authoriza,on?!! Resource user! Operation request! Response! Resource manager! Authorization Hooks! Reference monitor! Allowed?! YES/NO! Authorization policy! Alice, /etc/passwd, File_Read! Systems and Internet Infrastructure Security Laboratory (SIIS) 21

22 X Server & Many X Clients Retrofitting for Security Take the code written in a language of the programmers choice (for functionality) and retrofit with security code (mostly-automated) Consider authorization bypass vulnerabilities In these vulnerabilities, programmers forget to add code to control access to program resources REMOTE LOCAL Systems and and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 22

23 Retrofitting for Security Malicious Remote X Client Take the code written in a language of the programmers choice (for functionality) and retrofit with security code (mostly-automated) Consider authorization bypass vulnerabilities In these vulnerabilities, programmers forget to add code to control access to program resources REMOTE LOCAL Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 23

24 Illegal Information Flow Retrofitting for Security Take the code written in a language of the programmers choice (for functionality) and retrofit with security code (mostly-automated) Consider authorization bypass vulnerabilities In these vulnerabilities, programmers forget to add code to control access to program resources REMOTE LOCAL Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 24

25 Retrofitting for Security Desirable Information Flow Take the code written in a language of the programmers choice (for functionality) and retrofit with security code (mostly-automated) Consider authorization bypass vulnerabilities In these vulnerabilities, programmers forget to add code to control access to program resources LOCAL REMOTE Systems and and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 25

26 What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Systems and Internet Infrastructure Security Laboratory (SIIS) 26

27 Inferring Sensitive Operations What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Program Program Challenges Challenges User A User B Request Interface i Program A B o1 A. Identify securitysensitive resources F H C D E I J K L o2 o3 o4... on Programs manipulate many variables 7800 in X Server Of over 400 structures Many, many structuremember accesses Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 27

28 What Should a Programmer Do? Solution How would you ensure that all accesses to window objects in the X Server Requests are authorized? make choices In servers, client-request determines choices that client subjects can make in the program Choice : Resources: Determine which elements are chosen from containers. Operations: Determine which program path is selected for execution. Systems and and Internet Infrastructure Security Security (SIIS) Laboratory (SIIS) 28

29 Idea: Request Choices What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Program A Lookup Function using tainted variable User A Request Interface i B Container O User B o1 C v = Lookup(O,i) o2 o3 D o4 E F I K H J L Systems and and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 29

30 Idea: Request Choices What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Program A User A Request Interface i B Container O User B o1 C v = Lookup(O,i) o2 Op 1.0 D o3 o4 E F I K H J L Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 30

31 Idea: Request Choices What Should a Programmer Do? How would you ensure that all accesses to window objects in the Program X Server are authorized? A User A Request Interface i B Container O User B o1 C v = Lookup(O,i) o2 Op 1.0 D o3 o4 E Control Statement Predicated on a tainted variable F I K read v write v H J L Systems and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 31

32 Idea: Request Choices What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Program A User A Request Interface i B Container O User B o1 C v = Lookup(O,i) o2 Op 1.0 D o3 o4 Choice of operations E F I K read v write v H J L Op1.1 Op1.2 Op1.3 Systems and and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 32

33 Idea: Request Choices What Should a Programmer Do? How would you ensure that all accesses to window objects in the X Server are authorized? Program A User A Request Interface i B Container O User B o1 C v = Lookup(O,i) o2 Op 1.0 D o3 o4 E Security sensitive operation F I K read v write v H J L Op1.1 Op1.2 Op1.3 Systems and and Internet Infrastructure Security (SIIS) Laboratory Laboratory (SIIS) 33

34 Mediate SSOs Where should we place authorization hook checks Mediate all security-sensitive operations found Good: Enforce least-privilege flexibly Bad: Maximal number of hooks means Ensure at least one hook per security-sensitive operation Good: Minimal number of hooks Bad: Must ensure that all authorized subjects pass Idea: Determine if you have blocked enough Suppose OP-1 dominates OP-2, then if policy for OP-1 blocks all the unauthorized subjects for OP-2 Systems and Internet Infrastructure Security Laboratory (SIIS) 34

35 Future of Secure Programming Write your program with functionality in mind Determine security policies to be enforced on the program Semi-automated - e.g., use program analysis to find SSOs Use security policies to guide retrofitting of program with security code automatically Can it be done? Caveat: Some security knowledge is application-specific Caveat: Cannot retrofit for security from program code alone Systems and Internet Infrastructure Security Laboratory (SIIS) 35

36 Take Away Programming for security is difficult Programmers create flaws that are often accessible and exploitable by adversaries (vulnerabilities) Program analysis can find some flaws Static and dynamic, but limitations for each May need to fix program - security types and choice The future of secure programming may look very different Now: use favorite language for achieving function and try to add security code without creating flaws Future: use favorite language for achieving function and retrofit based on a security program Systems and Internet Infrastructure Security Laboratory (SIIS) 36