Falling into the link trap

This example illustrates the two main features of file access bugs.

• The program opens a file where the path name contains a ``hostile'' dirtectory. Hostile meaning that other users (read: potential attackers) can modify the contents of this directory.

  By far the most bugs of this type involved the /tmp directory; which is why this class of problems is frequently referred to as tempfile bugs. However, what is hostile depends on your type of application. For instance, consider a network server that implements the finger protocol. A client can connect to this service, send a user name, and the server will display all sorts of information about this user (e.g. whether he's currently logged in, etc).

  Commonly, this service will also display the contents of the .plan file in the user's home directory, if it exists. Of course, the server should treat the user's home directory as hostile, too: otherwise a user might make .plan a symbolic link to /etc/shadow; simply fingering himself would display the contents of the shadow file (assuming that the network service runs as root user, which it shouldn't do anyway; but that's a different issue we'll discuss in chapter 5).

• The program blindly follows a (symbolic) link. It's worth mentioning that while most published exploits use symbolic links, hard links will work sometimes, too. For instance, in the elm case, an attacker might also create a hard link like this:

      ln /etc/shadow /tmp/mbox.root
  

  When the super user reads his or her email with elm, it will overwrite the shadow file with the contents of root's mailbox!

In this chapter, we will discuss variations on this type of attack, and a number of defenses, effective and ineffective. The main reason I'm going to discuss the ineffective ones as well is because they're used pretty widely, and you need to be familiar with them in order to understand some of the more advanced attacks.