Computer Security. COMP 424 Lecture week 6 Program Security

Transcription

1 Computer Security COMP 424 Lecture week 6 Program Security

2 Program Security How do we keep programs free from flaws How do we protect resources against such flaws? Deals with the security aspects involved when writing programs. Chapter 5 will deal with how we measure trust or security of a program or operating system

3 Secure Programs Secure programs should enforce: Confidence Integrity Availability Evaluation of what is Secure is subject to the perspective of the evaluator Managers Developers Technicians Clients

4 General Definition of ProgramSecurity The quantity and types of faults in requirements design and code implementation are often used as evidence of a product's quality or security Fixing faults: Which is better? A program that undergoes very rigorous testing and is found to have 100 errors that are fixed, or A program that undergoes less scrutiny but only locates 20 errors that are found and fixed?

5 Actually... The answer is 2. History has shown that programs with a large number of identified faults tend to exhibit even more faults as time progresses. Fewer faults up front, even when less rigorous testing is done, is usually an indicator of well designed and fault free implementations.

6 Security Auditing Early security analysis attempts where based on Penetrate and patch Step 1: Attempt to cause the program to fail Step 2: create and apply an individual patch ASAP Step 3: Lather, rinse, repeat History also shows that this approach tends to cause more problems than it fixes. Why?

7 Patch Problems Repair pressures encourage narrow problem focus. The larger causes are often over looked Code is not 100% without side effects. Changing a small portion of code may cause subtle or overt changes in code behavior in other unlikely areas of code. Patches often cause serious functionality or performance problems.

8 A Better Approach... Compare and analyze the behavior of a product with the product's requirements and expectations? Does the program do what it is required to do and no more? Unexpected behaviors are considered program security flaws ethier: Faults: programmer error Failures: deviation from expected behavior

9 What causes flaws? Misunderstandings of program requirements Coding and typing mistakes Lack of expertise Failure of a single component Failure due to interaction of multiple components Intentionally induced flaws They fall into two categories: Inadvertent human errors Malicious intentional flaws

10 Which are more dangerous If flaws are either the result of human errors or intentional flaws which is more dangerous? Perception seems to be that the later is more dangerous: That intentional flaws and security breaches are more denagerous. The opposite is actaully true: Much more damage is allowed to happen by the existence of inadvertent human errors.

11 Why do human errors exist? Programs are unique and complex. PDAs probably have more computational power, flexibility and software components than an Apollo space craft. We are left only being able to test the most obvious and likely problems instead of exhaustive eliminations Software technology evolves far more rapidly than computer security techniques. Next year's software technology is already being used

12 Some common human errors Buffer Overflow User Data System Data or Code Resulting failure can be catastrophic and easily detected or can be extremely subtle (and useful to intruders)

13 Incomplete Mediation &parm1=john&parm2=doe&parm3=2002jan01 What if somebody enters &parm1=john&parm2=doe&parm3=1002jan01 This type of error can also be very problematic.

14 Time of check to Time of use Basically syncronization flaws A real problem with modern CPU design (Since instructions are no longer executed in the same order they were requested. Also problematic in software programming. Authorization could be granted based on some conditions Later conditions may change (l user gets fired) User is allowed access based on earlier descision that has been rendered obsolete but has not been updated.

15 Viruses and Malicious Code Malicious code can do much more (and often takes advantage of the errors) Terms like virus are horrible nomenclature. A virus is significantly different from its host biology (not even technically alive RNA yada yada yada) For computers though: a virus is just code; no different from any other program, application or executable. The computer doesn't know the difference.

16 Virus abilities Since a virus is really just a program what harm can it do? What abilities do they have? Any! If a program can do it, so can a virus. Corollary: Its not necessarily a bad thing... Viruses are not new. They have been documented well back to the early 70s. What is new is the explosion in the number of distinct instances and copies that have appeared

17 Kinds of Malicious Code A virus is usually a term reserved for malicious code that has the ability to pass on malicious code by modifying other nonmalicious programs. Many programs start with a jump statement that launches execution somewhere later than the start of the program. By altering this jump statement and inserting executable instructions in the segment that would have been jumped over. Code can also be relocated. Transient or resident viruses are possible. (TSR yick)

18 Trojan horses A trojan horse is a program that appears to fulfill its obvious intended behavior, but... Also performs some non obvious side effect. Example: A login script. Presents username and password prompts Performs obvious behavior of passing credentials on to operating system ALSO mails the credential to some agent(s).

19 Clues Suspicious originator and distribution of program Non technical Unexpected attributes Size Response time delays Undocumented features Always be suspicious

20 Logic Bombs A piece of malicious code that waits, inactive, until some condition occurs. Once the condition occurs the malicious code performs its neferious actions. Usually exploits the privileges of the user.

21 Trapdoors Trapdoors (or backdoors) are malicious features left in programs that allow some agent to circumvent security measures that expected to be enforced by the system.

22 Worms Worms are designed to spread copies of themselves throughout a network. (as standalone program) Usually result in denial of service on infected systems. Often take advantage of unexpected program behaviors Slammer Outlook mail macros

23 Rabbits are like worms but their sole intention is to... well... spread like rabbits until a particular resource (computation cycles, disk space or bandwidth) is exhausted.