1. CHAPTER 3 Program Security 1

2. Objectives 2  Defined the concept of secured program  differentiate malicious and non-malicious code  identify and describe programming errors with security implication  list and explain different types of viruses, how and where it attack and how it gain controls  explain virus signature  identify the impact of viruses to the computing system  discuss and explain various policies, procedures and technical controls against virus threats

3. Secure Program (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 3  Security implies some degree of trust that the program enforces expected confidentiality, integrity and availability.  The meaning of secure software is likely to get difference answer from different people.  This difference occurs because the importance of the characteristics depends on who is analyzing the software.

4. Fixing Faults (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 4  One approach of judging quality in security has been fixing faults.  Early work in computer security was based on the paradigm of “penetrate and patch” in which analysts searched for and repaired faults.  The test was considered to be “proof” of security; if the system withstood the attacks, it was considered secure.  Patch effort were largely useless, making the system less secure rather than more secure because they frequently introduced new faults.

5. Fixing Faults (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 5  Why :  The pressure to repair a specific problem encouraged a narrow focus on the fault itself and not on its context.  The fault often had nonobvious side effects in places other than the immediate area of the fault.  The fault could not be fixed properly because system functionality or performance would suffer as a consequence.

6. Unexpected Behavior (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 6  The inadequacies of penetrate-and-patch led researchers to seek a better way to be confident that code meets its security requirements.  Compare the requirements with the behavior – designer intended or users expected.  We call such unexpected behavior a program security flaw.  A program security flaw is an undesired program behavior caused by a program vulnerability

7. Types of Flaws (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 7  In the taxonomy, the inadvertent flaws fall into six categories:  Validation error (incomplete or inconsistence).  Domain error.  Serialization and aliasing.  Inadequate identification and authentication.  Boundary condition violation.  Other exploitable logic error.

8. Nonmalicious Program Errors (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 8  Human make many mistakes, most of which are unintentional and nonmalicious.  Many such errors cause program malfunction but do not lead to more serious security vulnerabilities.  3 main concern :  Buffer Overflows  Incomplete Mediation  Time-of-Check to Time-of-Use Errors

9. Buffer Flows (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 9  buffer (or array or string) is a space in which data can be held.  Because memory is finite, a buffer’s capacity is finite.  For this reason in many programming languages, the programmer must declare the buffer’s maximum size so that the compiler can set aside the amount of space.  Buffer overflow: when user input exceeds max buffer size  Extra input goes into unexpected memory locations  Attacker can run desired code, hijack program

10.  Malicious user enters > 1024 chars, but buf can only store 1024 chars; extra chars overflow buffer (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 10 void get_input() { char buf[1024]; gets(buf); } void main(int argc, char*argv[]){ get_input(); }

11. Buffer Flows (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 11  Example 1 :  Declare:char sample[10];  Run :sample[10] = ‘A’;  Error:Subscript is out of bounds.  Example 2 :  Declare:sample[ i ] = ‘A’  Run:for ( i=0; i<=9; i++ ) sample[ i ] sample[10] = ‘B’  Error:Overwrites an existing variable value.

12. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 12  Buffer may overflow into (and change):  User’s own data structures  User’s program code  System data structures  System program code

13. 13

14. Incomplete Mediation (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 14  Incomplete Mediation : routine’s failing on a data type error.  Another possibility is that the receiving program would continue to execute but would generate the very wrong result.  One way to address the potential problems is to anticipate them – written code to check for correctness on the client’s side, program can restrict choice only to a valid ones.

15. Incomplete Mediation (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 15  Example 1 :  Declare:int number;  Run :number = “two”;  Error:Wrong value in specified format  Example 2 :  Declare:in database we declare name length as 10 character  Run:We enter name = Christopher Columbus  Error:Database error

16. Time-of-Check to Time-of-Use Errors (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 16  Definition : instruction that appear to be adjacent may not actually be executed immediately after each other, either because of intentionally changed order or because of the effects of other processes in concurrent execution.  (A delay between checking permission to perform certain operations and using this permission may enable the operations to be changed)

17. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 17  Example:  1.User attempts to write 100 bytes at end of file “abc”.  Description of operation is stored in a data structure.  2.OS checks user’s permissions on copy of data structure.  3.While user’s permissions are being checked, user changes data structure to describe operation to delete file “xyz”.

18. Time-of-Check to Time-of-Use Errors (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 18  analogy:  To understand the nature of this flaw, consider a person’s buying a sculpture that cost RM100. The buyer remove five RM20 bill from a wallet, carefully counts them in front of the seller, and lays them on the table. When the seller turn around to write the receipt, the buyer takes back one RM20 bill. Then take the receipt and leaves with the sculpture.

19. Viruses and Other Malicious Code (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 19  By themselves, program are seldom security threats.  The program operate on data, taking action only when data and state changes trigger it.  Much of the work done by a program is invisible to the user, so they are not likely to be aware of any malicious activity.

20. Why Worry About Malicious Code (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 20  Malicious code can do much harm.  Writing a message on a computer screen, stopping a running program, generating a sound or erasing a stored files.  Malicious code has been around a long time.  Malicious code is still around and its effects are more pervasive.

21. Kind of Malicious Code Code TypeCharacteristics VirusAttach itself to program and propagates copies of itself to other programs. Trojan horseContains unexpected, additional functionality. Logic bombTriggers action when condition occurs. Time bombTriggers action when specified time occurs. TrapdoorAllows unauthorized access to functionality. WormPropagates copies of itself through a network. RabbitReplicates itself without limit to exhaust resource. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 21

22. How Viruses Attach (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 22  Appended viruses.  A program virus attaches itself to a program; then, whenever the program run, the virus activated. Easy to program.  Viruses that surround a program.  Virus that runs the original program but has control before and after its execution.  Integrated viruses and replacement.  Integrating itself into the original code of the target.

23. How Viruses Attach (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 23 Original Program + Virus Code Original Program Virus Code = Viruses appended to a program

24. How Viruses Attach (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 24 Original Program Virus Code Part (a) Viruses surrounding a program Virus Code Original Program Physically Logically Virus Code Part (b)

25. How Viruses Attach (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 25 Original Program + Virus Code Modified Program = Viruses integrated into a program

26. How Viruses Gain Control (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 26

27. Homes for Viruses (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 27  The virus writer may find these qualities appealing in a virus :  It is hard to detect.  It is not easily destroyed or deactivated.  It spreads infection widely.  It can re-infect its home program or the other programs.  It is easy to create.  It is machine independent and OS independent.

28. Issue of viral residence 28  One-Time Execution  The majority of viruses today execute only once, spreading their infection and causing their effect in that one execution  Boot Sector Viruses  The virus gains control very early in the boot process, before most detection tools are active, so that it can avoid, or at least complicate, detection

29. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 29  Memory-Resident Viruses  Resident routines are sometimes called TSRs or "terminate and stay resident" routines.  Virus writers also like to attach viruses to resident code because the resident code is activated many times while the machine is running. Each time the resident code runs, the virus does too. Once activated, the virus can look for and infect uninfected carriers  Other Homes for Viruses  One popular home for a virus is an application program. Many applications, such as word processors and spreadsheets, have a "macro" feature, by which a user can record a series of commands and repeat them with one invocation

30. Virus Signatures 30  A virus cannot be completely invisible. Code must be stored somewhere, and the code must be in memory to execute.  Each of these characteristics yields a telltale pattern, called a signature. The virus's signature is important for creating a program, called a virus scanner, that can detect and, in some cases, remove viruses.

31. Viruses (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 31  The Brain Virus.  The Internet Worm.  Code Red.  Web Bugs. Targeted Malicious Code  Trapdoors.  Salami Attack.  Rootkits and the Sony XCP  Privilege Escalation  Interface Illusions  Keystroke Logging  Man-in-the-Middle Attacks  Timing Attacks  Covert channel

32. Trapdoor (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 32  A trapdoor is an undocumented entry point to a module.  Developers insert trapdoors during code development, perhaps to test the module, to provide "hooks" by which to connect future modifications or enhancements, or to allow access if the module should fail in the future  Causes of Trapdoors  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

33. Salami attack (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 33  salami attack merges bits of seemingly inconsequential data to yield powerful results  Example:  small amounts are shaved from each computation and accumulated else where such as in the programmer's bank account Missing ½ cent Missing percentage Taking a bit from a bunch Charging higher fees Why do they happen? Sometimes programmers just except small errors Code many times it to large to look for salami type errors

34. Rootkits (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 34  rootkit is a piece of malicious code that goes to great lengths not to be discovered or, if discovered and removed, to reestablish itself whenever possible.  Example:  Intercepts commands in order to keep itself hidden  if a directory contains six files, one of which is the rootkit, the rootkit will pass the directory command to the operating system, intercept the result, delete the listing for itself, and display to the user only the five other files  XCP rootkit prevents a user from copying a music CD, while allowing the CD to be played as music.

35. Others  Privilege Escalation-Attack is a means for malicious code to be launched by a user with lower privileges but run with higher privileges  Interface Illusions - spoofing an attack in which all or part of a web page is false  Example:  to enter personal banking information on a site that is not the bank's,  to click yes on a button that actually means no  to scroll the screen to activate an event that causes malicious software to be installed on the victim's machine. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 35

36.  Keystroke Logging – keeps a copy of everything pressed  A keystroke logger can be independent (retaining a log of every key pressed) or it can be tied to a certain program, retaining data only when a particular program (such as a banking application) runs.  Man-in-the-Middle Attack- Malicious program exists between tow programs  Example:  a program that operated between your word processor and the file system, so that each time you thought you were saving your file, the middle program prevented that, or scrambled your text or encrypted your file  Timing Attack – identify how fast something happens (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 36

37. Covert Channels: Programs That Leak Information (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 37  programs that communicate information to people who should not receive it  Unnoticed communication and accompanies other information

38. Data written to a drive, sent across a network, placed in a file or printout Storage Channel – passes information based on presence or non-presence of data File lock Channel – lock or non-lock of file Timing Channels – varying speed in system or not using assigned computational time (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 38

39. Control Against Program Threats (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 39  There are many ways a program can fail and many ways to turn the underlying faults into security failures.  In this matters, we will look at three types of controls :  Developmental.  Operating System.  Administrative.

40. Developmental Controls (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 40  The nature of software development.  Development requires people who can do all tasks involved in developing a system. Specify the system Design the system Implement the system Test the system Review the system at various stages Document the system Manage the system Maintain the systems Typically it is not one person that does all of these

41.  Modularity, encapsulation and information hiding.  Modularization : process of dividing a task into subtasks.  Encapsulation : hides a component’s implementation details, but does not necessarily mean complete isolation.  Information hiding : think of a component as a black box, will certain well defined inputs and outputs and well defined function. (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 41

42. Developmental Controls (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 42  Peer reviews.  Review- presented formally  Walk-Through – creator leads and controls the discussion  Inspection – formal detailed analysis  Finding a fault and dealing with it:  By learning how, when, and why errors occur  By taking action to prevent mistakes  By scrutinizing products to find the instances and effects of errors that were missed.  Review, walk-through, inspection.  Hazard analysis.  Set of systematic techniques intended to expose potentially hazardous system state.

43.  Testing.  Activity that homes in on product quality : making the product failure free or failure tolerant.  Good design.  Design should try to anticipate faults and handle them in ways that minimize disruption and maximize security.  Using a philosophy of fault tolerance  Having a consistent policy for handling failures  Capturing the design rationale and history  Using design patterns (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 43

44. Developmental Controls (cont) (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 44  Prediction.  Important because we are always dealing with unwanted events that have negative consequences.  Static Analysis.  Examine several aspects of the design : control flow structure, data flow structure and data structure.  Configuration Management.  Process by which we control changes during development and maintenance.  Lesson From Mistake.  Document our decisions.

45. Operating System Controls (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 45  Trusted software.  Software that we know that the code has been rigorously developed and analyzed.  Mutual suspicion.  each program operates as if other routines in the system were malicious or incorrect  Access log.  Listing of who accessed which computer objects, when and for what amount of time.  Confinement.  Strictly limited in what system resources it can access.

46. Administrative Controls (c) by Syed Ardi Syed Yahya Kamal, UTM 2004 46  Standards of program development.  Guarantees program correctness, quality and security.  Separation of duties.  People are less tempted to do wrong if they concentrate in their job / task.