CMPT 473 Software Quality Assurance. Security. Nick Sumner - Fall 2014

Transcription

1 CMPT 473 Software Quality Assurance Security Nick Sumner - Fall 2014

2 Basic Security What are attributes of a secure program? CIA 2

3 Basic Security What are attributes of a secure program? CIA (C)onfidentiality No unauthorized information leaks 3

4 Basic Security What are attributes of a secure program? CIA (C)onfidentiality No unauthorized information leaks (I)ntegrity No unauthorized data manipulation/corruption 4

5 Basic Security What are attributes of a secure program? CIA (C)onfidentiality No unauthorized information leaks (I)ntegrity No unauthorized data manipulation/corruption (A)vailability The system must be accessible as needed (no DOS) 5

6 Basic Security What are attributes of a secure program? CIA (C)onfidentiality No unauthorized information leaks (I)ntegrity No unauthorized data manipulation/corruption (A)vailability The system must be accessible as needed (no DOS) (A2 )uthenticity All actions are genuine, taken by the parties they claim/appear to be 6

7 Why Is This Special? Poor security comes from unintended behavior. Quality software shouldn't allow such actions anyway. 7

8 Why Is This Special? Poor security comes from unintended behavior. Quality software shouldn't allow such actions anyway. While our testing techniques so far find some security issues, many slip through! Why? 8

9 Why Is This Special? Poor security comes from unintended behavior. Quality software shouldn't allow such actions anyway. While our testing techniques so far find some security issues, many slip through! Why? We cannot test everything 9

10 Why Is This Special? Poor security comes from unintended behavior. Quality software shouldn't allow such actions anyway. While our testing techniques so far find some security issues, many slip through! Why? We cannot test everything Concessions form part of an attack surface Networks, Software, People 10

11 Why Is This Special? Poor security comes from unintended behavior. Quality software shouldn't allow such actions anyway. While our testing techniques so far find some security issues, many slip through! Why? We cannot test everything Concessions form part of an attack surface Networks, Software, People Need additional policies & testing methods that specifically address security 11

12 What Could Possible Go Wrong? Many ways to attack different programs MITRE groups the most common into: 12

13 What Could Possible Go Wrong? Many ways to attack different programs MITRE groups the most common into: Insecure Interaction Data sent between components in an insecure fashion 13

14 What Could Possible Go Wrong? Many ways to attack different programs MITRE groups the most common into: Insecure Interaction Data sent between components in an insecure fashion Risky Resource Management Bad creation, use, transfer, & destruction of resources 14

15 What Could Possible Go Wrong? Many ways to attack different programs MITRE groups the most common into: Insecure Interaction Data sent between components in an insecure fashion Risky Resource Management Bad creation, use, transfer, & destruction of resources Porous Defenses Standard security practices that are missing or incorrect [ 15

16 Deeper Dive: Memory Safety Memory safety is a fundamental security issue for languages like C, C++, Assembly,. 16

17 Deeper Dive: Memory Safety Memory safety is a fundamental security issue for languages like C, C++, Assembly,. General idea: Accessing memory when you shouldn't be able to might read, write, or execute inappropriately 17

18 Deeper Dive: Memory Safety Memory safety is a fundamental security issue for languages like C, C++, Assembly,. General idea: Accessing memory when you shouldn't be able to might read, write, or execute inappropriately Classic example: stack buffer overflow attacks 18

19 Deeper Dive: Memory Safety Memory safety is a fundamental security issue for languages like C, C++, Assembly,. General idea: Accessing memory when you shouldn't be able to might read, write, or execute inappropriately Classic example: stack buffer overflow attacks Read more input into a buffer than the buffer can hold... 19

20 Deeper Dive: Memory Safety Memory safety is a fundamental security issue for languages like C, C++, Assembly,. General idea: Accessing memory when you shouldn't be able to might read, write, or execute inappropriately Classic example: stack buffer overflow attacks Read more input into a buffer than the buffer can hold... How many of you recall what a stack frame looks like? 20

21 Stack Buffer Overflows 0xFFF Addresses Stack void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } 0x000 21

22 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } 0x000 22

23 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } 0x000 23

24 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } Stack Frame for foo 0x000 24

25 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } Stack Frame for foo What can go wrong? 0x000 25

26 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = normal input + insecuredata 0x000 26

27 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = normal input + insecuredata 0x000 27

28 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = normal input + insecuredata The integrity of the secure data is corrupted. 0x000 28

29 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = normal input + insecuredata The integrity of the secure data is corrupted. 0x000 What else can go wrong? 29

30 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = input + payload address + payload 0x000 30

31 Stack Buffer Overflows 0xFFF Addresses Stack Previous Frame Return Address Old Frame Ptr securedata buffer[15] buffer[14]... buffer[0] Stack Growth void foo(char *input) { unsigned securedata; char buffer[16]; strcpy(buffer, input); } input = input + payload address + payload What does this mean? 0x000 31

32 Memory Safety Vulnerabilities come from reading/writing/freeing Out of bounds pointers Dangling pointers 32

33 Memory Safety Vulnerabilities come from reading/writing/freeing Out of bounds pointers Dangling pointers Why doesn't Java face this issue? 33

34 Memory Safety Vulnerabilities come from reading/writing/freeing Out of bounds pointers Dangling pointers Why doesn't Java face this issue? Is this intrinsic to languages like C++? Why/Why not? 34

35 Memory Safety Vulnerabilities come from reading/writing/freeing Out of bounds pointers Dangling pointers Why doesn't Java face this issue? Is this intrinsic to languages like C++? Why/Why not? Are these still a real issue? 35

36 Memory Safety Vulnerabilities come from reading/writing/freeing Out of bounds pointers Dangling pointers Why doesn't Java face this issue? Is this intrinsic to languages like C++? Why/Why not? Are these still a real issue? bid=

37 Another Case: SQL Injection SQL a query language for databases Queries like: SELECT grade,id FROM students WHERE name= + username; ID Name Grade 0 Alice 92 1 Bob 87 2 Mallory 75 37

38 Another Case: SQL Injection SQL a query language for databases Queries like: SELECT grade,id FROM students WHERE name= + username; ID Name Grade 0 Alice 92 1 Bob 87 2 Mallory 75 Values for name, grade often come from user input. 38

39 Another Case: SQL Injection SQL a query language for databases Queries like: SELECT grade,id FROM students WHERE name= + username; ID Name Grade 0 Alice 92 1 Bob 87 2 Mallory 75 Values for name, grade often come from user input. Why is this a problem? 39

40 Another Case: SQL Injection username = 'bob'; DROP TABLE students What happens? 40

41 SQL Injection [ [ The user may include commands in their input! 41

42 SQL Injection [ [ The user may include commands in their input! Need to sanitize the input before use 42

43 SQL Injection [ [ The user may include commands in their input! Need to sanitize the input before use How would you prevent this problem? 43

44 A Subtle Problem in General The problems may be much more subtle: User A can read files X,Y,Z and write to S,T User B can read files X,Y,S and write to Z,T How can we ensure that no information from A is ever written to Z? 44

45 A Subtle Problem in General The problems may be much more subtle: User A can read files X,Y,Z and write to S,T User B can read files X,Y,S and write to Z,T How can we ensure that no information from A is ever written to Z? Can you envision a scenario that creates this problem? 45

46 A Subtle Problem in General The problems may be much more subtle: User A can read files X,Y,Z and write to S,T User B can read files X,Y,S and write to Z,T How can we ensure that no information from A is ever written to Z? Care may be required to enforce access control policies 46

47 A Subtle Problem in General The problems may be much more subtle: User A can read files X,Y,Z and write to S,T User B can read files X,Y,S and write to Z,T How can we ensure that no information from A is ever written to Z? Care may be required to enforce access control policies Discretionary access control owner determines access 47

48 A Subtle Problem in General The problems may be much more subtle: User A can read files X,Y,Z and write to S,T User B can read files X,Y,S and write to Z,T How can we ensure that no information from A is ever written to Z? Care may be required to enforce access control policies Discretionary access control owner determines access Mandatory access control clearance determines access 48

49 Assuring Security Make risky operations someone else's job e.g. Google Checkout, PayPal, Amazon, etc. 49

50 Assuring Security Make risky operations someone else's job e.g. Google Checkout, PayPal, Amazon, etc. Define rigorous security policies What are your CIAA security criteria? 50

51 Assuring Security Make risky operations someone else's job e.g. Google Checkout, PayPal, Amazon, etc. Define rigorous security policies What are your CIAA security criteria? Follow secure design & coding policies And include them in your review criteria 51

52 Assuring Security Make risky operations someone else's job e.g. Google Checkout, PayPal, Amazon, etc. Define rigorous security policies What are your CIAA security criteria? Follow secure design & coding policies And include them in your review criteria Apple secure coding policies CERT Top 10 Practices Mitre Mitigation Strategies 52

53 Assuring Security Make risky operations someone else's job e.g. Google Checkout, PayPal, Amazon, etc. Define rigorous security policies What are your CIAA security criteria? Follow secure design & coding policies And include them in your review criteria Formal certification 53

54 Common Proactive Approaches How are these techniques applied? 54

55 Common Proactive Approaches How are these techniques applied? Security must be part of design Prepared Statements, Safe Arrays, etc. 55

56 Common Proactive Approaches How are these techniques applied? Security must be part of design Prepared Statements, Safe Arrays, etc. Regular security audits Retrospective analysis & suggestions 56

57 Common Proactive Approaches How are these techniques applied? Security must be part of design Prepared Statements, Safe Arrays, etc. Regular security audits Retrospective analysis & suggestions Penetration testing Can someone skilled break it? 57

58 Security Overall Security is now a pressing concern for all software 58

59 Security Overall Security is now a pressing concern for all software Old software was designed in an era of naiveté and is often vulnerable/broken 59

60 Security Overall Security is now a pressing concern for all software Old software was designed in an era of naiveté and is often vulnerable/broken New software is built to perform sensitive operations in a multiuser and networked environment. 60

61 Security Overall Security is now a pressing concern for all software Old software was designed in an era of naiveté and is often vulnerable/broken New software is built to perform sensitive operations in a multiuser and networked environment. Not planning for security concerns from the beginning is a broken approach to development 61