Back to Cptr427Winter2010

Program Security

This chapter deals with the writing of programs! Although this is not a programming class, we must answer two questions about programming:

1. How do we keep programs free from flaws?
2. How do we protect computing resources against programs that contain flaws?

3.1 Secure Programs

1. Early work used the "penetrate and patch" paradigm, but this often introduced new faults. Why?

   1. Focus on the faulty code ignored the broader context (requirements etc.) that may have lead to the fault.
   2. The fault often had side effects in places other than the immediate are of the fault.
   3. Fixing one problem often caused a failure somewhere else, or the patch addressed the problem in only one place.
   4. The fault could not be fixed properly because system functionality or performance would suffer as a consequence.

2. Penetrate and Patch failures led to a new method which exams a program's behavior and compares it to the expected behavior. This is called Program Verification and applies to all aspects of program behavior, not just to the program's security behavior.

   1. Abhorent behavior that undermines security (which is almost any abnormal behavior) is called a program security flaw.

   2. program flaws can be included via inadvertent human errors or
   3. ... malicious intentially introduced flaws. Either way its bad!
3. Security is fundamentally hard - i.e. it is not decidable to determine if a program is operating as intended. There is no silver bullet. Fundamentally we should check two things:
   1. A program will do what we list it should do.
   2. A program does not do what we list it should not do.
4. Types of Flaws
   1. Validation error: permission checks incorrectly implemented
   2. Domain error: access control inappropriately applied
   3. serialization and aliasing: program gave access before checking if access is allowed or access through an alias was not caught.
   4. inadequate identification / authentication: If you don't authenticate correctly, you can't authorize correctly.
   5. boundary condition violation: common issue where the "first" or "last" case is incorrectly checked or missed.
   6. logic errors

3.2 Nonmalicious Program errors

There are three common mistakes that programmers make that lead to security breaches:

1. Buffer Overflows: A buffer is a space in which data can be held. A buffer overflow is when the data input into the buffer is larger than the buffer and the program writes the data beyond the buffer's alocated space and overwrites other data or program space.

2. Incomplete Mediation: There is an improper transfer of information from the user to the program. I.e. the process of gathering information does not check or validate the user input. A simple example is assigning a string such as "one" to a integer variable. A more serious example would be using the following for a password: junk' OR TRUE --.

Back to Cptr427Winter2010

1. Time-of-Check to Time-of-Use Errors: This is the serialization and synchronization flaw scenario where input is checked correctly, but then allowed to be changed before it is operated on. Therefore a sort of "bait-and-switch" routine may be taking place. An example of this is client side validation in web forms. With a simple proxy (e.g. Tamper Data or WebScarab).

3.3 Viruses and other Malicious code

1. Define a virus.
2. At minimum, what must a Virus do?

3.4 Targeted Malicious Code

1. A trapdoor is an undocumented entry point to a module
   1. maliciously inserted or
   2. used for testing
2. Name one infamous root kit implementation distributed in a commercial product.

3.5 Controls agains program threats

Since this is not a programming class, we will forgo this section for now.