Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing...
Transcript of Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing...
![Page 1: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/1.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Module: Future of Secure Programming
Professor Trent JaegerPenn State University
1
1
![Page 2: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/2.jpg)
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Programmer’s Problem
• Implement a program
‣ Without creating vulnerabilities
• What is a vulnerability?
2Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Little Survey
2
• What does “program for security” mean?
• Have you ever “programmed for security”?
• When do 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?
2
![Page 3: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/3.jpg)
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Programmer’s Problem
• Implement a program
‣ Without creating vulnerabilities
• What is a vulnerability?
3
3
![Page 4: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/4.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Software Vulnerabilities• Vulnerability combines
‣ A flaw
‣ Accessible to an adversary
‣ Who can exploit that flaw
• Which would you focus on to prevent vulnerabilities?
4
4
![Page 5: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/5.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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?
5
5
![Page 6: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/6.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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?
6
6
![Page 7: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/7.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
7
7
![Page 8: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/8.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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 flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
8Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis • Explore all possible executions of a program!
‣ All possible inputs !
‣ All possible states!
8 8
![Page 9: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/9.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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 flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
9Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis • Provides an approximation of behavior!
• �Run in the aggregate�!
‣ Rather than executing on ordinary states!
‣ Finite-sized descriptors representing a collection of states!
• �Run in non-standard way�!
‣ Run in fragments!
‣ Stitch them together to cover all paths!
• Runtime testing is inherently incomplete, but static analysis can cover all paths!
10
9
![Page 10: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/10.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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 flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
10Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Static Analysis Example • Descriptors represent the sign of a value!
‣ Positive, negative, zero, unknown!
• For an expression, c = a * b!
‣ If a has a descriptor pos!
‣ And b has a descriptor neg!
• What is the descriptor for c after that instruction?!
• How might this help?!
11 10
![Page 11: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/11.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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 flaw (e.g., buffer overflow)?
• What are limitations of runtime analysis?
11Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Descriptors • Choose a set of descriptors that !
‣ Abstracts away details to make analysis tractable!
‣ Preserves enough information that key properties hold!
• Can determine interesting results!
• Using sign as a descriptor!
‣ Abstracts away specific integer values (billions to four)!
‣ Guarantees when a*b = 0 it will be zero in all executions!
• Choosing descriptors is one key step in static analysis !
12
11
![Page 12: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/12.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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?
12
12
![Page 13: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/13.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
13
13
![Page 14: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/14.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Preventing Vulnerabilities • What can the programmer do to secure their program?
14
14
![Page 15: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/15.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• 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
15-1
![Page 16: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/16.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• 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
15-2
![Page 17: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/17.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• 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
15-3
![Page 18: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/18.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
15
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Denning’s Lattice Model • Formalizes information flow models!
‣ FM = {N, P, SC, /, >}
• 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
15-4
![Page 19: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/19.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• 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!
16-1
![Page 20: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/20.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• 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!
16-2
![Page 21: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/21.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• 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!
16-3
![Page 22: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/22.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
16
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Implicit and explicit flows • Explicit!
‣ Direct transfer to b from a (e.g., b = a)!
• 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!
16-4
![Page 23: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/23.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from 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!
17-1
![Page 24: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/24.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from 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!
17-2
![Page 25: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/25.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
‣ Simple security & ★-property
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from 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!
17-3
![Page 26: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/26.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Information Flow Control
17
• What is it?
‣ Simple security & ★-property
•
Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Semantics
• Program is secure if:!
‣ Explicit flow from 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!
17-4
![Page 27: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/27.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
18-1
![Page 28: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/28.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
Example 1 Object obj;int i;obj = obj + i;
18-2
![Page 29: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/29.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety
18
Example 1 Object obj;int i;obj = obj + i;X
18-3
![Page 30: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/30.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Build on Type Safety• A type-safe
language maintains the semantics of types. E.g., can’t add int’s to Object’s.
18
Example 1 Object obj;int i;obj = obj + i;X
18-4
![Page 31: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/31.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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.
18
Example 1 Object obj;int i;obj = obj + i;X
18-5
![Page 32: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/32.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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.
18
Example 1 Object obj;int i;obj = obj + i;
Example 2 String proc_obj(Object o);...main(){ Object obj; String s = proc_obj(obj);
...}
X
18-6
![Page 33: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/33.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
19-1
![Page 34: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/34.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;
19-2
![Page 35: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/35.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-3
![Page 36: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/36.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-4
![Page 37: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/37.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
• Security-typing is compositional
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;X
19-5
![Page 38: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/38.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Labeling Types
• Key insight: label types with security levels
• Security-typing is compositional
19
Example 1 int{high} h1,h2;int{low} l;l = 5;h2 = l;h1 = h2 + 10;l = h2 + l;
Example 2 String{low} proc_obj(Object{high} o);...main(){ Object{high} obj; String{low} s; s = proc_obj(obj); ...}
X
19-6
![Page 39: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/39.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implicit Flows
20
intLow mydata = 0;
intLow mydata2 = 0;
if (testHigh)
mydata = 1;
else
mydata = 2;
mydata2 = 0;
printLow(mydata2);
printLow(mydata);
…
Static (virtual) tagging
Causes type error at compile-time
mydata contains information about test so it can no longer be Low,but mydata2 is outside the
conditional, so it is untainted by test
20-1
![Page 40: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/40.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Implicit Flows
20
intLow mydata = 0;
intLow mydata2 = 0;
if (testHigh)
mydata = 1;
else
mydata = 2;
mydata2 = 0;
printLow(mydata2);
printLow(mydata);
…
Static (virtual) tagging
Causes type error at compile-time
mydata contains information about test so it can no longer be Low,but mydata2 is outside the
conditional, so it is untainted by test
20-2
![Page 41: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/41.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
21
Resource manager!
!!
Resource user!
Operation request! Response!
Authorization policy!
Reference monitor!
Allowed?! YES/NO!
Authorization Hooks!
‹Alice, /etc/passwd, File_Read›!
What!is!authoriza,on?!!
21
![Page 42: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/42.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
22Systems and Internet Infrastructure Security (SIIS) Laboratory Page
X Server & Many X Clients
REMOTE
LOCAL
22
![Page 43: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/43.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
23Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Malicious Remote X Client
REMOTE
LOCAL
23
![Page 44: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/44.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
24Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Illegal Information Flow
REMOTE
LOCAL
24
![Page 45: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/45.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
25Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Desirable Information Flow
LOCAL
REMOTE
25
![Page 46: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/46.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to all security-sensitive
window objects in the X Server are authorized?
26
26
![Page 47: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/47.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
27Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Program Challenges
A. Identify security-sensitive resources
• Programs manipulate many variables• 7800 in X Server• Of over 400 structures • Many, many structure-
member accesses
Program Challenges
Inferring Sensitive Operations
BRequest Interface
i
C
User A
User B
D
A
FI
JH
K
L
E
Program
o1
o2
o3
o4
on
.
.
.
27
![Page 48: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/48.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
28Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Solution
• 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.
Requests make choices
28
![Page 49: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/49.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
29Systems and Internet Infrastructure Security (SIIS) Laboratory Page
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
K
L
E
Program
Container O
Idea: Request ChoicesLookup Function using tainted variable
29
![Page 50: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/50.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
30Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
K
L
E
Program
Container O
Op 1.0
30
![Page 51: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/51.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
31Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Control Statement Predicated on atainted variable
31
![Page 52: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/52.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
32Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Op1.3Op1.2Op1.1
Choice of operations
32
![Page 53: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/53.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
What Should a Programmer Do?• How would you ensure that all accesses to window objects in the
X Server are authorized?
33Systems and Internet Infrastructure Security (SIIS) Laboratory Page
Idea: Request Choices
write v
o1
o2
o3
o4
BRequest Interface
i
Cv = Lookup(O,i)
User A
User B
D
A
FI
JH
read v
K
L
E
Program
Container O
Op 1.0
Op1.3Op1.2Op1.1
Security sensitiveoperation
33
![Page 54: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/54.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
Mediate SSOs• Where should we place authorization hooks?
• 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…
34
34
![Page 55: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/55.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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
35
35
![Page 56: Module: Future of Secure Programmingtrj1/cse543-f18/slides/cse543-secure-program.pdf• Fuzz testing is “black-box testing” — do not need to examine the program code to run •](https://reader030.fdocuments.in/reader030/viewer/2022040805/5e4272ac80488915fe2171df/html5/thumbnails/56.jpg)
Systems and Internet Infrastructure Security Laboratory (SIIS) Page
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”
36
36