The interpretation of the SUID bit is as follows. When a program is executed, the file’s mode bits are examined. If the SUID bit is enabled, the kernel obtains the UID of the file’s owner. When the process context is being initialized for the program to run in, the EUID and SSUID are set to the UID of the file’s owner. If you run a SUID program, the EUID and SSUID of the new process will be set to the owner UID, but the RUID remains the same. If the program is owned by root, you will have gained root privileges on the system.

The passwd program used to change your password is an example of an SUID program. Other programs, such as the notorious UNIX sendmail daemon, might be configured as SGID for group mail. Because SUID root programs effectively give the requesting user root privileges, these programs need to be well written.

Note that you should never have SUID shell scripts on a system. A race condition attack is possible in which the hacker can trick the operating system into executing an arbitrary shell script with root privileges instead of the SUID root shell script stored on the system. Some operating systems, such as IBM’s AIX, do not even allow you to create SUID shell scripts. If you need to write privileged scripts, learn Perl and write your scripts in its more tightly controlled environment. Unfortunately, in at least one published attack on Perlin which its similar SUID capabilities are exploited.

The UNIX operating system is full of SUID and SGID programs. You can easily display a list of these programs using the find command. If your environment consists of many commercial products, too, it’s likely that additional SUID or SGID programs will be installed. Escalating privileges in programs through the use of SUID and SGID semantics is a common programming practice in UNIX. Sadly, these programs are the most commonly exploited items on computers today. Privileged programs executable by arbitrary users can be probed in a number of ways. If you try sending a range of invalid parameters to a program, and the program crashes, a buffer overflow attack probably is lurking in that program.

One defense is to diligently monitor SUID activities on your system. Access control does not provide a complete security solution in itself. You should regularly inspect your system for new SUID or SGID programs. Also, you should install intrusion detection products that monitor privilege transitions in real time and alert you when one of these programs changes or is executed by a user.

If you prefer, tools such as Tripwire from COAST are available for interval monitoring of important files such as SUID and SGID executables. With Tripwire, you can compute cryptographic checksums on files and store the results in a database. Periodically, you can recalculate the checksums again on the files to see whether they were modified.

Are You Remembering to Ask Tough Questions?

Are you periodically stopping to ask yourself how a hacker uses information you are learning? You should be. Hackers do. Here are a couple of ideas.

You might have a program that scans your system occasionally looking for executable programs created by users. A hacker can use knowledge of when you scan to keep the execute bit turned off, turning it back on only before running the program. To automate the task, the hacker can put a wrapper around the program that first turns the execute bit on, runs the program, and then turns the execute bit off.

A hacker can leak information to someone else by setting the permission bits so that everyone can read a file. Although in some cases, UNIX (by poor design) requires world-readable or world-writable directories, the general rule is that there should be no permission bit settings of this type.

Certain user files and directories control security aspects of the user’s login session. If the permission bits of one of these files has been set so that others can write to the file, a security breach is imminent. If the permission bits have been changed by another user, get a cup of coffee or tea. You have some work ahead to discover the trail of activities.

If you’re running a real-time IDS, you can catch these events as they occur.

Link Counts, Hard Links, and Symbolic Links

The standard UNIX file system is divided into a number of storage chunks. Two important chunks are the areas set aside for the inodes of the file system and the data blocks making up the contents of the file system entries. A file and a directory are both entries in the file system, even though a directory can contain one or more files or subdirectories. Each file or directory defined in the data blocks area is associated with an inode, so the file has a pointer back to the inode that describes it.

Two or more different files can refer to the same data bits making up a file. This process is accomplished by creating one of two types of links. You first create file A. At this point, the inode for A has a link count of 1. Next, you explicitly create file B by declaring that it is a hard link to file A. This can be done from the command line or through a subroutine. A directory entry is created for file B; the contents of file A are not copied. Instead, the directory entry for file B points back to the inode for file A. When B is created, the link count in the inode for file A is incremented by one. You can repeat this process as many times as you like.

A symbolic link is stored differently in the directory. If you had created B as a symbolic link, it would have the string name of the target file, namely “A,” stored in the directory entry for B. Symbolic links were originally created to overcome a limitation in early UNIX systems that did not allow you to define hard links across different file systems. POSIX allows an option for the creation of hard links across file systems. Therefore, you should consult the reference manuals for your specific UNIX version to learn about the limitations of hard and symbolic links and how various system routines behave when a link is passed as a parameter.