Program Security I

Tom Kelliher, CS 325

Sept. 25, 2006

Administrivia

Announcements

Presentations Wednesday. Ten minutes, tops.

Assignment

``Harden'' your presentations.

From Last Time

Outline

1. Secure programs.

2. Non-Malicious program errors.

3. Viruses and other malicious program errors.

Coming Up

Presentations Wednesday.

Secure Programs

1. At this level, we're addressing how a program handles security itself, not assistance it receives from the OS or other, external, security mechanisms.

2. What do we mean when we say a program is secure?
   1. Requires much effort and time to cause a failure.

   2. Program has been in use for a long time with no failures.

   3. No faults and, therefore, no failures.

   4. Meets the level of security specified in the requirements.

   5. Other measures?

Non-Malicious Program Errors

Programmer had no malevolent intent. Perhaps just ``clueless.''

Buffer Overflows

1. General idea:
   1. Overflow a buffer with a code segment.

   2. Segment overwrites existing code, a return address, etc.

   3. Original program runs your code as whatever user.

   4. You now have the privileges of that user.

      If root, it's time to party.

2. How an we mediate this type of an error?

Lack of Mediation

1. Unvalidated, unchecked data values.

2. Garbage input values can lead to a program entering an invalid state, crashing, etc., resulting in denial of service.

   Several years ago, numerous standard Unix tools were fed garbage data. Nearly all crashed.

Time-of-Check to Time-of-Use; Incomplete Mediation

1. Data values are checked and validated, but can be changed before use.

   Synchronization problem.

2. General idea:
   1. Submit data that will validate.

   2. Validation begins and completes.

   3. Change data.

   4. Use data.

3. Causes:
   1. Client/Server interactions where client-side does validation.

      What prevents a hacker from accessing the server interface directly?

   2. Internal validation in which there is a delay between validation and use with the data left accessible.

      Example: bank account transactions queued up on a linked list prior to being applied to the database.

4. Result: Gain arbitrary unauthorized access.

5. Prevention: Copy data to a secure location; validate and use from there.

   Example: OS kernel copies system call parameters to its own memory space before validating and using.

Viruses and Other Malicious Program Errors

Programmer did have malevolent intent.

Background

1. Where does this stuff come from?
   1. Potentially, any executable or source file you download.

   2. Viruses, spyware.

   3. Hacked open source repositories.

2. Types:
   1. Virus: Attaches itself to executable and begins propagating.

   2. Trojan horse: Contains unexpected functionality.

      ``Innocent'' example: Grand Theft Auto's Hot Coffee scene.

   3. Logic bomb: Activates when certain condition achieved.

   4. Time bomb: Activates at certain time.

   5. Trapdoor: Allows unauthorized access.

   6. Worm: Propagates through network.

   7. Rabbit: Massive replication, leading to resource exhaustion and DOS.

A Few Examples

1. Root kits. Hide malevolent activity with ``patched'' versions of standard system utilities, such as ls, ps, netstat, etc.

2. The Morris worm.
   1. First Internet worm, unleashed Nov. 2, 1988.

   2. Not created to ``cause damage,'' but a program flaw caused this to become a ``rabbit,'' resulting in severe DOS problems.

   3. Written by Robert Tappan Morris at Cornell; released at MIT for purposes of disguise. Morris is now an assoc. profat MIT.

      His father worked for the NSA.

   4. Exploited flaws in 4 BSD:
      1. Tried to match encrypted passwords in /etc/passwd through a brute force attack on ``common'' passwords, then words in a local dictionary.

         Fixes: Use of shadow password file; password salts; enforced use of better passwords.

      2. Buffer overflow in fingerd -- gets().

      3. Debug trapdoor in sendmail -- allowed command execution. At that time, sendmail commonly ran as root!

      4. Trusted hosts in rsh.

   5. Overview of infection mechanism, assuming a shell is running on target machine, or source machine has established an SMTP connection to target and is transmitting commands:
      1. Establishment of bootstrap on target machine:
         1. Break-in via rsh and .rhosts.

         2. Commands sent to sendmail in DEBUG mode.

      2. Open socket on infecting machine for bootstrap to connect to.

      3. Bootstrap code connects to source machine (server) and authenticates.

         It retrieves binary copies of the server code for Sun and VAX architectures as well as source code.

      4. Across network connection, server would attempt to infect target. If successful, it would disconnect. If unsuccessful, it would remove evidence and disconnect.

      5. The newly-created worm on the newly-infected host hides itself.

      6. Worm now attempts to determine host connectivity, through use of netstat and reading system host files.

      7. Worm chooses a set of hosts to attempt to infect.

      8. Worm attempts to infect other hosts, using:
         1. rsh via .rhosts.

         2. Overflow fingerd's input buffer, causing execve("/bin/sh", 0, 0) to execute on VAXen.

         3. Use the sendmail trapdoor.

      9. Attempt to find easy hosts to connect to, searching for .rhosts, etc. files.

      10. Tried password attacks. This, in conjunction with .rhosts and .forward files would lead to likely new hosts to infect.

      For details, see http://homes.cerias.purdue.edu/~spaf/tech-reps/823.pdf.

Tom Kelliher