To get around these problems, UNIX allows programs to be endowed with privilege. Processes executing these programs can assume another UID or GID when they're running. A program that changes its UID is called a SUID program (set-UID); a program that changes its GID is called a SGID program (set-GID). A program can be both SUID and SGID at the same time.
When a SUID program is run, its effective UID[22] becomes that of the owner of the file, rather than of the user who is running it. This concept is so clever that AT&T patented it.[23]
5.5.1 SUID, SGID, and Sticky Bits
If a program is SUID or SGID, the output of the ls -l command will have the x in the display changed to an s. If the program is sticky, the last x changes to a t as shown in Table 5.13 and Figure 5.3.
Figure 5.3: Additional file permissions
Contents | Permission | Meaning |
|---|---|---|
---s------ | SUID | A process that execs a SUID program has its effective UID set to be the UID of the program's owner. |
------s--- | SGID | A process that execs a SGID program has its effective GID changed to the program's GID. Files created by the process can have their primary group set to this GID as well, depending on the permissions of the directory in which the files are created. Under Berkeley-derived UNIX, a process that execs an SGID program also has the program's GID temporarily added to the process's list of GIDs. Solaris and other System V-derived versions of UNIX use the SGID bit on data files to enable mandatory file locking. |
---------t | sticky | This is obsolete with files, but is used for directories. See "The Origin of `Sticky' " sidebar later in this chapter. |
In each of the cases above, the designator letter is capitalized if the bit is set, and the corresponding execute bit is not set. Thus, a file that has its sticky and SGID bits set, and is otherwise mode 444, would appear in an ls listing as
% ls -l /tmp/example
-r--r-Sr-T 1 root user 12324 Mar 26 1995 /tmp/example
An example of a SUID program is the su command,
% ls -l /bin/su
-rwsr-xr-x 1 root user 16384 Sep 3 1989 /bin/su
%
5.5.2 Problems with SUID
Any program can be SUID, SGID, or both SUID and SGID. Because this feature is so general, SUID/SGID can open up some interesting security problems.
For example, any user can become the superuser simply by running a SUID copy of csh that is owned by root. Fortunately, you must be root already to create a SUID version of csh that is owned by root. Thus, an important objective in running a secure UNIX computer is to ensure that somebody who has superuser privileges will not leave a SUID csh on the system, directly or indirectly.
If you leave your terminal unattended, an unscrupulous passerby can destroy the security of your account simply by typing the commands:
% cp /bin/sh /tmp/break-acct
% chmod 4755 /tmp/break-acct
%
These commands create a SUID version of the sh program. Whenever the attacker runs this program, the attacker becomes you - with full access to all of your files and privileges. The attacker might even copy this SUID program into a hidden directory so that it would only be found if the superuser scanned the entire disk for SUID programs. Not all system administrators do such scanning on any regular basis.
Note that the program copied need not be a shell. Someone with malicious intent can cause you misery by creating a SUID version of other programs. For instance, consider a SUID version of the editor program. With it, not only can he read or change any of your files, but he can also spawn a shell running under your UID.
Most SUID system programs are SUID root; that is, they become the superuser when they're executing. In theory, this aspect is not a security hole, because a compiled program can perform only the function or functions that were compiled into it. (That is, you can change your password with the passwd program, but you cannot alter the program to change somebody else's password.) But many security holes have been discovered by people who figured out ways of making a SUID program do something that it was not designed to do. In many circumstances, programs that are SUID root could easily have been designed to be SUID something else (such as daemon, or some UID created especially for the purpose). Too often, SUID root is used when something with less privilege would be sufficient.
5.5.3 SUID Shell Scripts
Under most versions of UNIX, you can create shell scripts[24] that are SUID or SGID. That is, you can create a shell script and, by setting the shell script's owner to be root and setting its SUID bit, you can force the shell script to execute with superuser privileges.
[24] Actually, any interpreted scripts.
You should never write SUID shell scripts.
Because of a fundamental flaw with the UNIX implementation of shell scripts and SUID, you cannot execute SUID shell scripts in a completely secure manner on systems that do not support the /dev/fd device. This flaw arises because executing a shell script under UNIX involves a two-step process: when the kernel determines that a shell script is about to be run, it first starts up a SUID copy of the shell interpreter, then the shell interpreter begins executing the shell script. Because these two operations are performed in two discrete steps, you can interrupt the kernel after the first step and switch the file that the shell interpreter is about to execute. In this fashion, an attacker could get the computer to execute any shell script of his or her choosing, which essentially gives the attacker superuser privileges. Although this flaw is somewhat mitigated by the /dev/fd device, even on systems that do support a /dev/fd device, SUID shell scripts are very dangerous and should be avoided.
Some modern UNIX systems ignore the SUID and SGID bits on shell scripts for this reason. Unfortunately, many do not. Instead of writing SUID shell scripts, we suggest that you use the Perl programming language for these kinds of tasks. A version of Perl called taintperl [25] will force you to write SUID scripts that check their PATH environment variable and that do not use values supplied by users for parameters such as filenames unless they have been explicitly "untainted." Perl has many other advantages for system administration work as well.
5.5.3.1 write: Example of a possible SUID/SGID security hole
The authors of SUID and SGID programs try to ensure that their software won't create security holes. Sometimes, however, a SUID or SGID program can create a security hole if the program isn't installed in the way the program author planned.
For example, the write program, which prints a message on another user's terminal, is SGID tty. For security reasons, UNIX doesn't normally let users read or write information to another's terminal; if it did, you could write a program to read another user's keystrokes, capturing any password that she might type. To let the write program function, every user's terminal is also set to be writable by the tty group. Because write is SGID tty, the write program lets one user write onto another user's terminal. It first prints a message that tells the recipient the name of the user who is writing onto her terminal.
But write has a potential security hole - its shell escape. By beginning a line with an exclamation mark, the person using the write program can cause arbitrary programs to be run by the shell. (The shell escape is left over from the days before UNIX had job control. The shell escape made it possible to run another command while you were engaged in a conversation with a person on the computer using write.) Thus, write must give up its special privileges before it invokes a shell; otherwise, the shell (and any program the user might run) would inherit those privileges as well.
The part of the write program that specifically takes away the tty group permission before the program starts up the shell looks like this:
setgid(getgid()); /* Give up effective group privs */
execl(getenv("SHELL"),"sh","-c",arg,0);
Notice that write changes only its GID, not its effective UID. If write is installed SUID root instead of SGID tty, the program will appear to run properly but any program that the user runs with the shell escape will actually be run as the superuser! An attacker who has broken the security on your system once might change the file permissions of the write program, leaving a hole that he or she could exploit in the future. The program, of course, will still function as before.
5.5.3.2 Another SUID example: IFS and the /usr/lib/preserve hole
Sometimes, an interaction between a SUID program and a system program or library creates a security hole that's unknown to the author of the program. For this reason, it can be extremely difficult to know if a SUID program contains a security hole or not.
One of the most famous examples of a security hole of this type existed for years in the program called /usr/lib/preserve (which is now given names similar to /usr/lib/ex3.5preserve). This program, which is used by the vi and ex editors, automatically makes a backup of the file being edited if the user is unexpectedly disconnected from the system before writing out changes to the file. The preserve program writes the changes to a temporary file in a special directory, then uses the /bin/mail program to send the user a notification that the file has been saved.
Because people might be editing a file that was private or confidential, the directory used by the older version of the preserve program was not accessible by most users on the system. Therefore, to let the preserve program write into this directory, and let the recover program read from it, these programs were made SUID root.
Three details of the /usr/lib/preserve implementation worked together to allow knowledgeable system crackers to use the program to gain root privileges:
preserve was installed SUID root.
preserve ran /bin/mail as the root user to alert users that their files had been preserved.
preserve executed the mail program with the system() function call.
The problem was that the system function uses sh to parse the string that it executes. There is a little-known shell variable called IFS, the internal field separator, which sh uses to figure out where the breaks are between words on each line that it parses. Normally, IFS is set to the white space characters: space, tab, and newline. But by setting IFS to the slash character (/) then running vi, and then issuing the preserve command, it was possible to get /usr/lib/preserve to execute a program in the current directory called bin. This program was executed as root. (/bin/mail got parsed as bin with the argument mail.)
If a user can convince the operating system to run a command as root, that user can become root. To see why this is so, imagine a simple shell script which might be called bin, and run through the hole described earlier:[26]
[26] There is actually a small bug in this shell script; can you find it?
#
# Shell script to make an SUID-root shell
#
cd /homes/mydir/bin
cp /bin/sh ./sh
# Now do the damage!
chown root sh
chmod 4755 sh
This shell script would get a copy of the Bourne shell program into the user's bin directory, and then make it SUID root. Indeed, this is the very way that the problem with /usr/lib/preserve was exploited by system crackers.
The preserve program had more privilege than it needed - it violated a basic security principle called least privilege. Least privilege states that a program should have only the privileges it needs to perform the particular function it's supposed to perform, and no others. In this case, instead of being SUID root, /usr/lib/preserve should have been SGID preserve, where preserve would have been a specially created group for this purpose. Although this restriction would not have completely eliminated the security hole, it would have made its presence considerably less dangerous. Breaking into the preserve group would have only let the attacker view files that had been preserved.
Although the preserve security hole was a part of UNIX since the addition of preserve to the vi editor, it wasn't widely known until 1986. For a variety of reasons, it wasn't fixed until a year after it was widely publicized.
NOTE: If you are using an older version of UNIX that can't be upgraded, remove the SUID permission from /usr/lib/preserve to patch this security hole.
Newer editions of UNIX sh ignore IFS if the shell is running as root or if the effective user ID differs from the real user ID. Many other shells have similarly been enhanced, but not all have. The idea that there are still programs being shipped by vendors in 1995 with this same IFS vulnerability inside is interesting and very depressing. The general problem has been known for over 10 years, and people are still making the same (dumb) mistakes.
5.5.4 Finding All of the SUID and SGID Files
You should know the names of all SUID and SGID files on your system. If you discover new SUID or SGID files, somebody might have created a trap door that they can use at some future time to gain superuser access. You can list all of the SUID and SGID files on your system with the command:
# find / \(-perm -004000
-o -perm -002000 \) -type f -print
This find command starts in the root directory (/) and looks for all files that match mode 002000 (SGID) or mode 004000 (SUID). The -type f option causes the search to be restricted to files. The -print option causes the name of every matching file to be printed.
NOTE: If you are using NFS, you should execute find commands only on your file servers. You should further restrict the find command so that it does not try to search networked disks. Otherwise, use of this command may cause an excessive amount of NFS traffic on your network. To restrict your find command, use the following:
# find / \( -local -o -prune \)
\( -perm -004000 -o -perm -002000 \) -type f -print
NOTE: Alternatively, if your find command has the -xdev option, you can use it to prevent find from crossing filesystem boundaries. To search the entire filesystem using this option means running the command multiple times, once for each mounted partition.
Be sure that you are the superuser when you run find, or you may miss SUID files hidden in protected directories.
5.5.4.1 The ncheck command
The ncheck command is an old UNIX command that prints a list of each file on your system and its corresponding inode number. When used with the -s option, ncheck restricts itself to listing all of the "special" inodes on your system - such as the devices and SUID files.
The ncheck command runs on a filesystem-by-filesystem basis. For example:
# ncheck -s | cat -ve -
/dev/dsk/c0t3d0s0:
125 /dev/fd/0
513 /dev/fd/1
514 /dev/fd/2
...
533 /dev/fd/21
534 /dev/fd/22
535 /dev/fd/23
3849 /sbin/su
3850 /sbin/sulogin
(The cat -ve command is present in the above to print control characters so that they will be noticed, and to indicate the end of line for filenames that end in spaces.)
The ncheck command is very old, and has largely been superseded by other commands. It may not be present on all versions of UNIX, although it is present in SVR4. If you run it, you may discover that it is substantially faster than the find command, because ncheck reads the inodes directly, rather than searching through files in the filesystem. However, ncheck still needs to read some directory information to obtain pathnames, so it may not be that much faster.
Unlike find, ncheck will locate SUID files that are hidden beneath directories that are used as mount-point. In this respect, ncheck is superior to find, because find can't find such files because they do not have complete pathnames as long as the mounts are mounted.
5.5.5 Turning Off SUID and SGID in Mounted Filesystems
If you mount remote network filesystems on your computer, or if you allow users to mount their own floppy disks or CD-ROMS, you usually do not want programs that are SUID on these filesystems to be SUID on your computer as well. In a network environment, honoring SUID files means that if an attacker manages to take over the remote computer that houses the filesystem, he can also take over your computer, simply by creating a SUID program on the remote filesystem and running the program on your machine. Likewise, if you allow users to mount floppy disks containing SUID files on your computer, they can simply create a floppy disk with a SUID ksh on another computer, mount the floppy disk on your computer, and run the program - making themselves root.
You can turn off the SUID and SGID bits on mounted filesystems by specifying the nosuid option with the mount command. You should always specify this option when you mount a foreign filesystem unless there is an overriding reason to import SUID or SGID files from the filesystem you are mounting. Likewise, if you write a program to mount floppy disks for a user, that program should specify the nosuid option (because the user can easily take his or her floppy disk to another computer and create a SUID file).
For example, to mount the filesystem athena in the /usr/athena directory from the machine zeus with the nosuid option, type the command:
# /etc/mount -o nosuid zeus:/athena /usr/athena
Some systems also support a -nodev option that causes the system to ignore device files that may be present on the mounted partition. If your system supports this option, you should use it, too. If your user creates a floppy with a mode 777 kmem, for instance, he can subvert the system with little difficulty if he is able to mount the floppy disk. This is because UNIX treats the /dev/kmem on the floppy disk the same way that it treats the /dev/kmem on your main system disk - it is a device that maps to your system's kernel memory.
5.5.6 SGID and Sticky Bits on Directories
Although the SGID and sticky bits were originally intended for use only with programs, Berkeley UNIX, SunOS, Solaris and other operating systems also use these bits to change the behavior of directories, as shown in Table 5.14.
Bit | Effect |
|---|---|
SGID bit | The SGID bit on a directory controls the way that groups are assigned for files created in the directory. If the SGID bit is set, files created in the directory have the same group as the directory if the process creating the file also is in that group. Otherwise, if the SGID bit is not set, or if the process is not in the same group, files created inside the directory have the same group as the user's effective group ID (usually the primary group ID). |
Sticky bit | If the sticky bit is set on a directory, files inside the directory may be renamed or removed only by the owner of the file, the owner of the directory, or the superuser (even if the modes of the directory would otherwise allow such an operation); on some systems, any user who can write to a file can also delete it. This feature was added to keep an ordinary user from deleting another's files in the /tmp directory. |
For example, to set the mode of the /tmp directory on a system so any user can create or delete her own files but can't delete another's files, type the command:
# chmod 1777 /tmp
Many older versions of UNIX (System V prior to Release 4, for instance) do not exhibit either of these behaviors. On those systems, the SGID and sticky bits on directories are ignored by the system. However, on a few of these older systems (including SVR3), setting the SGID bit on the directory resulted in "sticky" behavior.
5.5.7 SGID Bit on Files (System V UNIX Only): Mandatory Record Locking
If the SGID bit is set on a nonexecutable file, AT&T System V UNIX implements mandatory record locking for the file. Normal UNIX record locking is discretionary; processes can modify a locked file simply by ignoring the record-lock status. On System V UNIX, the kernel blocks a process which tries to access a file (or the portion of the file) that is protected with mandatory record locking until the process that has locked the file unlocks it. Mandatory locking is enabled only if none of the execute permission bits are turned on.
Mandatory record locking shows up in an ls listing in the SGID position as a capital "S" instead of a small "s":
% ls -F data*
-rw-rwS--- 1 fred 2048 Dec 3 1994 database
-r-x--s--x 2 bin 16384 Apr 2 1993 datamaint*
Post a Comment