With the theory out of the way, let's examine the risks. The primary risks are

· Data disclosure. I don't want to belabor an obvious point, but this is so incredibly common that it deserves some attention. Users and programs create files in /tmp—it's a digital scrap yard. If the user doesn't specify file permissions, the umask value applies. Commonly, the default umask of 022 is set, and the file is given world readable permissions—any user on the system can read the file.

On a typical multiuser system, it is not unusual to find copies of scripts containing database passwords, confidential business data, sensitive log information, and core files containing encrypted passwords in /tmp. The same goes for user home directories and shared areas that have not been locked down to prevent access by Other. Why break in if you can read your way to root?

· Unauthorized data modification/deletion. This happens in two common ways. First, through lax user practices—someone sets world writable permissions on a file. The second way is via world writable directories. If I create a file in a directory that is world writable, any local user can subsequently delete/modify it.

This is also true for filesystems shared via NFS.

The only exception to this is directories that have the sticky bit set (such as /tmp). If the file permissions are locked down, only the owner can write to the file. This is not always obvious, because the world writable directory might be the parentof the parent of the current directory, or the parent of the parent's parent. In an extreme case, if the / directory is world writable, an attacker can replace any file on the system—for example, by moving /usr/sbin out of the way and creating a replacement /usr/sbin, filled with Trojan programs of their choosing. This can easily lead to a total system compromise.

The bottom line is that it's not just the parent directory that counts—but every directory along the way up to slash (/)! This problem is surprisingly common on system and application directories.

· Resource consumption. Each filesystem is built with a finite number of inodes. When all inodes are consumed, no more files can be written to the filesystem, regardless of available free space. This can cause system daemons to crash or hang when /tmp is involved. Unless file giveaways have been disabled in the kernel, the culprit can cast the blame on another user simply by changing the ownership of the files she has created to the victim via the chown command. Consuming all free space is another approach.

· Temporary files with predictable filenames. Programs can be subverted to overwrite or remove arbitrary files if they create temporary files with predictable filenames in directories writable by Other (commonly /tmp). Other users can guess a filename in advance and create a symbolic link to a system file. When the program runs, it writes data to the system file resulting in data corruption. If that's the passwd file, you have a denial of service attack on your hands. This is incredibly common—especially in application code and administrators'shell scripts.

· Named pipes that trip up the find command. By default, most UNIX systems ship with root crontab entries to run the find command. In addition, root users often run find to search for particular files. A user can create a named pipe that will cause find to hang when it reaches the pipe. The find command will open the pipe for reading and block (that is, hang) waiting for data. Because no EOF (End of File) will be sent, find will hang until it is killed. An attacker can use this method to prevent the administrator from finding the attacker's unauthorized set-uid programs. A further attack on some versions of find is to embed commands in the filename. If find passes the file to an exec command switch, the shell will interpret any shell meta characters (in this case ";") and execute the embedded commands.

Privileged shell scripts that read filenames from the filesystem and blindly pass them to another program can be subverted. SNI (Secure Networks Inc.) posted an advisory way back in 1996 about this problem. This weakness is still present in some commercial distributions today.

· World readable/writable named pipes. One method for processes to communicate with one another is through the file system—using a named pipe. If the pipe has been created with weak permissions, an attacker can read and write to the named pipe subverting/crashing the process at the other end of the pipe or reading privileged data.

· Race conditions. Matt Bishop coined the acronym TOCTTOU (Time Of Check To Time Of Use) for a common race condition—namely, when a program checks for a particular characteristic of an object and takes some action based on the assumption that the characteristic still holds true. However, if a program is subject to race conditions, an attacker can swap the object between the time the check is made and the subsequent use of the object. This tricks the program, which will then operate on the wrong object.