1. Lecture 14 Overview

2. Secure programs Security implies some degree of trust that the program enforces expected – confidentiality, – integrity, and – availability. Why is it so hard to write secure programs? – Axiom (Murphy): Programs have bugs – Corollary: Security-relevant programs have security bugs CS 450/650 Lecture 14: Program Security 2

3. Flaws, faults, and failures A flaw is a problem with a program A security flaw is a problem that affects security in some way – Confidentiality, integrity, availability Flaws come in two types: faults and failures A fault is a mistake “behind the scenes” – An error in the code, data, specification, process, etc. – A fault is a potential problem CS 450/650 Lecture 14: Program Security 3

4. Flaws, faults, and failures A failure is when something actually goes wrong – “Goes wrong” means deviation from desired behaviour, not necessarily from specified behaviour! A failure is the user/outside view The quantity and types of faults in requirements design and code implementation are often used as evidence of a product‘s quality or security CS 450/650 Lecture 14: Program Security 4

5. Types of security flaws: Genesis Some flaws are intentional – Malicious flaws are intentionally inserted to attack If it's meant to attack some particular system, we call it a targeted malicious flaw – Nonmalicious (but intentional) flaws are often features that are meant to be in the system are correctly implemented, but can cause a failure when used by an attacker Most security flaws are caused by unintentional program errors CS 450/650 Lecture 14: Program Security 5

6. Types of security flaws Most common sources of unintentional security flaws – Buffer overflows – Incomplete mediation – TOCTTOU errors (race conditions)‏ CS 450/650 Lecture 14: Program Security 6

7. Buffer overflows The single most commonly exploited type of security flaw Simple example: #define LINELEN 1024 char buffer[LINELEN]; gets(buffer); or strcpy(buffer, argv[1]); CS 450/650 Lecture 14: Program Security 7

8. Where a Buffer Can Overflow CS 450/650 Lecture 14: Program Security 8

9. Kinds of buffer overflows In addition to the classic attack which overflows a buffer on the stack to jump to shellcode, there are many variants: – Attacks which work when a single byte can be written past the end of the buffer often caused by a common off-by-one error – Overflows of buffers on the heap instead of the stack – Jump to other parts of the program, or parts of standard libraries, instead of shellcode CS 450/650 Lecture 14: Program Security 9

10. Defences against buffer overflows Use a language with bounds checking – And catch those exceptions! Non-executable stack – memory page is either writable or executable Stack (and code) at random addresses – Linux 2.6 does this “Canaries” that detect if the stack has been overwritten before return from each function – This is a compiler feature CS 450/650 Lecture 14: Program Security 10

11. Integer overflows Machine integers can represent only a limited set of numbers – might not correspond to programmer's model Program assumes integer is always positive – overflow will make (signed) integer wrap and become negative, which will violate assumption Program casts large unsigned integer to signed integer Result of a mathematical operation causes overflow Attacker can pass values to program that will trigger overflow CS 450/650 Lecture 14: Program Security 11

12. Format string vulnerabilities Unfiltered user input is used as format string in printf(), fprintf(), sprintf(),... – printf(buffer) instead of printf("%s", buffer) First one will parse buffer for %'s and use whatever is currently on the stack to process found format parameters – printf("%s%s%s%s") will likely crash program – printf("%x%x%x%x") will dump parts of the stack – The %n format parameter will cause writes to the stack CS 450/650 Lecture 14: Program Security 12

13. Incomplete mediation Inputs to programs are often specified by untrusted users – Web-based applications are a common example Users sometimes mistype data in forms – Phone number: 51998884567 – Email: iang#cs.uwaterloo.ca An application needs to ensure that what user has entered constitutes a meaningful request – This is called mediation CS 450/650 Lecture 14: Program Security 13

14. Incomplete mediation Incomplete mediation occurs when the application accepts incorrect data from user Sometimes this is hard to avoid – Phone number: 519-886-4567 – This is a reasonable entry, that happens to be wrong CS 450/650 Lecture 14: Program Security 14

15. Why do we care? What happens if someone fills in: – DOB: 98764874236492483649247836489236492 Buffer overflow? – DOB: '; DROP DATABASE clients -- SQL injection? We need to make sure that any user-supplied input falls within well-specified values – known to be safe CS 450/650 Lecture 14: Program Security 15

16. Client-side mediation forms that do client-side mediation – When you click “submit”, Javascript code will first run validation checks on the data you entered – If you enter invalid data, a popup will prevent you from submitting it Related issue: client-side state – Many web sites rely on the client to keep state for them – Put hidden fields in the form which are passed back to the server when user submits the form CS 450/650 Lecture 14: Program Security 16

17. Client-side mediation Problem: what if the user – Turns off Javascript? – Edits the form before submitting it? – Writes a script that interacts with the web server instead of using a web browser at all? – Connects to the server “manually”? telnet server.com 80 Note that the user can send arbitrary (unmediated) values to the server this way The user can also modify any client-side state CS 450/650 Lecture 14: Program Security 17

18. Defences against incomplete mediation Client-side mediation is an OK method to use in order to have a friendlier user interface – but is useless for security purposes. You have to do server-side mediation – whether or not you also do client-side CS 450/650 Lecture 14: Program Security 18

19. Defences against incomplete mediation For values entered by the user – Always do very careful checks on the values of all fields – These values can potentially contain completely arbitrary 8-bit data and be of any length For state stored by the client: – Make sure the client has not modified the data in any way CS 450/650 Lecture 14: Program Security 19

20. Time-Of-Check To Time-Of-Use errors TOCTTOU (“TOCK-too”) errors – Also known as “race condition” errors These errors occur when the following happens: – User requests the system to perform an action – The system verifies the user is allowed to perform the action – The system performs the action CS 450/650 Lecture 14: Program Security 20

21. The problem State of the system changed between the check for permission and the execution of operation File whose permissions were checked for writeability by the user (file_he_owns) wasn't the same file that was later written to (/etc/passwd)‏ – Even though they had the same name (logfile) at different points in time CS 450/650 Lecture 14: Program Security 21

22. Program Flaws Taxonomy of flaws: – how (genesis) – when (time) – where (location) the flaw was introduced into the system 22 CS 450/650 Lecture 16: Malicious Codes

23. Security Flaws by Genesis Genesis – Intentional Malicious: Trojan Horse, Trapdoor, Logic Bomb, Worms, Virus Non-malicious – Inadvertent Validation error Domain error Serialization error Identification/authentication error Other error 23 CS 450/650 Lecture 16: Malicious Codes

24. Flaws by time Time of introduction – During development Requirement/specification/design Source code Object code – During maintenance – During operation 24 CS 450/650 Lecture 16: Malicious Codes

25. Flaws by Location Location – Software Operating system: system initialization, memory management, process management, device management, file management, identification/authentication, other Support tools: privileged utilities, unprivileged utilities Application – Hardware 25 CS 450/650 Lecture 16: Malicious Codes

26. Lecture 16 Malicious Codes CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Csilla Farkas and Brandon Phillips

27. Malware? CS 450/650 Lecture 16: Malicious Codes 27

28. Kinds of Malicious Codes Virus: a program that attaches copies of itself into other programs. – Propagates and performs some unwanted function – Viruses are not programs – Definition from RFC 1135: A virus is a piece of code that inserts itself into a host [program], including operating systems, to propagate. It cannot run independently. It requires that its host program be run to activate it. 28 CS 450/650 Lecture 16: Malicious Codes

29. Kinds of Malicious Code Worm: a program that propagates copies of itself through the network. – Independent program. – May carry other code, including programs and viruses. – Definition from RFC 1135: A worm is a program that can run independently, will consume the resources of its host [machine] from within in order to maintain itself and can propagate a complete working version of itself on to other machines. 29 CS 450/650 Lecture 16: Malicious Codes

30. Kinds of Malicious Code Rabbit/Bacteria: make copies of themselves to overwhelm a computer system's resources – Denying the user access to the resources Logic/Time Bomb: programmed threats that lie dormant for an extended period of time until they are triggered – When triggered, malicious code is executed 30 CS 450/650 Lecture 16: Malicious Codes

31. Kinds of Malicious Code Trojan Horse: secret, undocumented routine embedded within a useful program – Execution of the program results in execution of secret code Trapdoor: secret, undocumented entry point into a program, used to grant access without normal methods of access authentication Dropper: Not a virus or infected file – When executed, it installs a virus into memory, on to the disk, or into a file 31 CS 450/650 Lecture 16: Malicious Codes

32. Malware Evolution 1980s – Malware for entertainment (pranks) – 1983: “virus” – 1988: Internet Worm 1990s – Malware for social status / experiments – 1990: antivirus software Early 2000s – Malware to spam Mid 2000s – Criminal malware CS 450/650 Lecture 16: Malicious Codes 32

33. Malware Evolution CS 450/650 Fundamentals of Integrated Computer Security 33

34. Change in Malware Dynamics Dynamics of Malware have changed and the visible front has diminished. CS 450/650 Fundamentals of Integrated Computer Security 34 Worms Spam Phishing Bots Viruses Spyware Targeted Trojans Rootkits “Spear Phishing” Stable Front Growing Front Front in Decline Visibility Propagation Panda Software

35. Malware Targets Platform% *nix (Linux, BSD)0.052% Mac (OS X primarily)0.005% Mobile (Symbian, WinCE)0.020% Other (MySQL, IIS, DOS)0.012% Windows (XP SP2, SP3, Vista, 7)99.91% CS 450/650 Lecture 16: Malicious Codes 35

36. Malware Proliferation (2009-2010) CS 450/650 Lecture 16: Malicious Codes 36 (Microsoft Security Intelligence Report 9)‏

37. Malware Families in 2010 CS 450/650 Lecture 16: Malicious Codes 37

38. Regional Threat Categories (Microsoft Security Intelligence Report 9)‏ CS 450/650 Lecture 16: Malicious Codes 38

39. Virus Lifecycle Dormant phase: the virus is idle – not all viruses have this stage Propagation phase: the virus places an identical copy of itself into other programs of into certain system areas Triggering phase: the virus is activated to perform the function for which it was created Execution phase: the function is performed – The function may be harmless or damaging 39 CS 450/650 Lecture 16: Malicious Codes

40. Virus Types Parasitic virus: – Attaches itself to a file and replicates when the infected program is executed – most common form Memory resident virus: – lodged in main memory as part of a resident system program – Virus may infect every program that executes 40 CS 450/650 Lecture 16: Malicious Codes

41. Virus Types Boot Sector Viruses: – Infects the boot record and spreads when system is booted – Gains control of machine before the virus detection tools – Very hard to notice Macro Virus: – virus is part of the macro associated with a document 41 CS 450/650 Lecture 16: Malicious Codes

42. Virus Types Stealth virus: – A form of virus explicitly designed to hide from detection by antivirus software Polymorphic virus: – A virus that mutates with every infection making detection by the “signature” of the virus difficult 42 CS 450/650 Lecture 16: Malicious Codes

43. How Viruses Append 43 Original program virus Original program virus Virus appended to program += CS 450/650 Lecture 16: Malicious Codes

44. How Viruses Append 44 Original program virus Original program Virus-1 Virus surrounding a program += Virus-2 CS 450/650 Lecture 16: Malicious Codes

45. How Viruses Append 45 Original program virus Original program Virus-1 Virus integrated into program += Virus-2 Virus-3 Virus-4 CS 450/650 Lecture 16: Malicious Codes

46. How Viruses Gain Control Virus V has to be invoked instead of target T – V overwrites T – V changes pointers from T to V 46 CS 450/650 Lecture 16: Malicious Codes

47. High risk virus properties Hard to detect Hard to destroy Spread infection widely Can re-infect Easy to create Machine independent 47 CS 450/650 Lecture 16: Malicious Codes

48. Virus Signatures Storage pattern – Code always located on a specific address – Increased file size Execution pattern Transmission pattern Polymorphic Viruses 48 CS 450/650 Lecture 16: Malicious Codes

49. Antivirus Approaches Detection: – determine infection and locate the virus Identification: – identify the specific virus Removal: – remove the virus from all infected systems, so the disease cannot spread further Recovery: – restore the system to its original state 49 CS 450/650 Lecture 16: Malicious Codes

50. Preventing Virus Infection Prevention: – Good source of software installed – Isolated testing phase – Use virus detectors Limit damage: – Make bootable diskette – Make and retain backup copies important resources 50 CS 450/650 Lecture 16: Malicious Codes

51. Nyxem Email Virus Estimate of total number of infected computers is between 470K and 945K At least 45K of the infected computers were also compromised by other forms of spyware or botware Spread 51 CS 450/650 Lecture 16: Malicious Codes

52. Worm Self-replicating (like virus) Objective: system penetration (intruder) Phases: dormant, propagation, triggering, and execution Propagation: – Searches for other systems to infect e.g., host tables – Establishes connection with remote system – Copies itself to remote system – Execute 52 CS 450/650 Lecture 16: Malicious Codes

53. Code-Red Worm On July 19, 2001, more than 359,000 computers connected to the Internet were infected with the Code-Red (CRv2) worm in less than 14 hours Spread 53 CS 450/650 Lecture 16: Malicious Codes

54. Sapphire/Slammer Worm was the fastest computer worm in history – doubled in size every 8.5 seconds – infected more than 90 percent of vulnerable ~75K hosts within 10 minutes. 54 CS 450/650 Lecture 16: Malicious Codes

55. Witty Worm reached its peak activity after approximately 45 minutes – at which point the majority of vulnerable hosts had been infected World USA 55 CS 450/650 Lecture 16: Malicious Codes

56. Browser-based Exploits 10%Adobe Flash 8%RealPlayer 8%Microsoft (Microsoft Security Intelligence Report 6)‏ CS 450/650 Lecture 16: Malicious Codes 56

57. Bank Logons A Washington Mutual Bank account in the U.S. with an available balance of $14,400 is priced at 600 euros ($924), while a Citibank UK account with an available balance of 10,044 pounds is priced at 850 euros ($1,310). It may appear to be less dangerous to resell access to a bank account rather than to use it directly. McAfee ©2008 CS 450/650 Lecture 16: Malicious Codes 57

58. Lecture 16 Targeted Malware CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Csilla Farkas and Brandon Phillips

59. Targeted Malicious Code Trapdoor – undocumented entry point to a module – forget to remove them – intentionally leave them in the program for testing – intentionally leave them in the program for maintenance of the finished program, or – intentionally leave them in the program as a covert means of access to the component after it becomes an accepted part of a production system 59 CS 450/650 Lecture 16: Targeted Malicious Codes

60. Targeted Malicious Code Salami Attack – a series of many minor actions that together results in a larger action that would be difficult or illegal to perform at once – Ex. Interest computation rootkit – A program or coordinated set of programs designed to gain control over a computer system or network of computing systems 60 CS 450/650 Lecture 16: Targeted Malicious Codes

61. Targeted Malicious Code Privilege Escalation – a means for malicious code to be launched by a user with lower privileges but run with higher privileges Interface illusion – a spoofing attack in which all or part of a web page is false Keystroke Logging 61 CS 450/650 Lecture 16: Targeted Malicious Codes

62. Targeted Malicious Code Man-in-the-Middle Attacks Timing Attacks – attempts to compromise a cryptosystem by analyzing the time taken to execute cryptographic algorithms Covert Channels – programs that leak information – Ex. Hide data in output 62 CS 450/650 Lecture 16: Targeted Malicious Codes

63. Covert Channel - Trojan Horse John Spy Only John is permitted to access the document MS Word Document Spy’s Document copy TH install copy 63 CS 450/650 Lecture 16: Targeted Malicious Codes

64. Covert Channel Two active agents – Sender (has access to unauthorized information) e.g., Trojan Horse in MS Word – Receiver (reads sent information) e.g., program creating the copy Encoding schema – How the information is sent e.g., – File F exists  0 – File F is does not exist  1 Synchronization – e.g., when to check for existence of F 64 CS 450/650 Lecture 16: Targeted Malicious Codes

65. Storage Covert Channels Based on properties of resources – pass information by using presence or absence of objects in storage Examples: – File locks – Delete/create file – Memory allocation 65 CS 450/650 Lecture 16: Targeted Malicious Codes

66. File Lock Covert Channel 66

67. File Existence Channel Used to Signal 100 67

68. Timing Covert Channel Time is the factor – how fast – pass information using the speed at which things happen Examples: – Processing time – Transmission time 68 CS 450/650 Lecture 16: Targeted Malicious Codes

69. Covert Timing Channel 69

70. Covert Channel Detection and Removal Identification: – Shared resources – Program code correctness – Information flow analysis Removal: – Total removal – may not be possible – Reduce bandwidth 70 CS 450/650 Lecture 16: Targeted Malicious Codes

71. Controls Against Program Threats Prevent Threats during software development – Modularity security analysts must be able to understand each component as an independent unit and be assured of its limited effect on other components 71 CS 450/650 Lecture 16: Targeted Malicious Codes

72. Controls Against Program Threats Prevent Threats during software development – Encapsulation hide a component's implementation details minimize interfaces to reduce covert channels – Information hiding a component as a kind of black box components will have limited effect on other components 72 CS 450/650 Lecture 16: Targeted Malicious Codes

73. Controls Against Program Threats Peer Reviews – Hazard Analysis set of systematic techniques to expose potentially hazardous system states – Testing unit testing, integration testing, function testing, performance testing, acceptance testing, installation testing, regression testing 73 CS 450/650 Lecture 16: Targeted Malicious Codes

74. Controls Against Program Threats Good Design – Using a philosophy of fault tolerance – Have a consistent policy for handling failures – Capture the design rationale and history – Use design patterns Prediction – predict the risks involved in building and using the system 74 CS 450/650 Lecture 16: Targeted Malicious Codes

75. Controls Against Program Threats Static Analysis – Use tools and techniques to examine characteristics of design and code to see if the characteristics warn of possible faults Configuration Management – control changes during development and maintenance Analysis of Mistakes Proofs of Program Correctness – Can we prove that there are no security holes? 75 CS 450/650 Lecture 16: Targeted Malicious Codes

76. Operating System Controls on Use of Programs Trusted Software – code has been rigorously developed and analyzed Functional correctness Enforcement of integrity Limited privilege Appropriate confidence level 76 CS 450/650 Lecture 16: Targeted Malicious Codes

77. Operating System Controls on Use of Programs Mutual Suspicion – assume other program is not trustworthy Confinement – limit resources that program can access Access Log – list who access computer objects, when, and for how long 77 CS 450/650 Lecture 16: Targeted Malicious Codes

78. Administrative Controls Standards of Program Development Standards of design Standards of documentation, language, and coding style Standards of programming Standards of testing Standards of configuration management Security Audits Separation of Duties 78 CS 450/650 Lecture 16: Targeted Malicious Codes