Temporary File Attack

The simplest example of this attack is a tool storing secret information into a temporary file.

Consider the following code:

#!/bin/sh

SECRETDATA="My password is 12345."

echo > /tmp/mysecretdata

chmod og-rwx /tmp/mysecretdata

echo "$SECRETDATA" >> /tmp/mysecretdata

The attack:

Create a tool that watches for the file /tmp/mysecretdata to appear. (Although this can be done with a shell script, it probably won’t be fast enough to work very often. Use the File System Events API in C instead.)

Upon detecting the existence of the path, do this:

FILE *fp=fopen("/tmp/mysecretdata", "r");

If the attacker manages to open the file before the script executes the chmod command, it can continue to read data from the file for as long as it keeps the file open.

Mitigation:

There are two things you must do to fix this:

• Always use the umask command to specify initial permissions on the file when you create it.

• Always create temporary files with the mktemp command. This creates a new file with the specified template, ensuring that a file or symbolic link with that name does not already exist.

For example:

#!/bin/sh

SECRETDATA="My password is 12345."

umask 0177

FILENAME="$(mktemp /tmp/mytempfile.XXXXXX)"

echo "$SECRETDATA" >> "$FILENAME"

However, assuming you actually intend to use the data again in the future, this mitigation is probably not sufficient either, for the reasons described in the next attack.

Input File Attack

A similar attack can be performed on files used as inputs to shell scripts.

Consider a script that executes the following code:

#!/bin/sh

echo "My password is secret!" > /tmp/mypublicdata

...

PUBLICDATA="$(cat /tmp/mypublicdata)"

echo "$PUBLICDATA" | nc 192.168.1.102 3333

This script sends the contents of a temporary file to port 3333 of another computer at IP number 192.168.1.102 using the nc utility.

The attack:

Create a tool that watches for the file /tmp/mydata to appear. (Although this can be done with a shell script, it probably won’t be fast enough to work very often. Use the File System Events API in C instead.)

Upon detecting the existence of the path, do this:

unlink("/tmp/mypublicdata");

unlink("/etc/myscretdata", "/tmp/mypublicdata");

If the attacker manages to do this before the script reads the file, then your secret password (presumably 12345, from the previous script) is sent unencrypted over port 3333. The attacker can then sniff for traffic on that port, and can log into your account (or at least unlock your luggage).

Mitigation:

This is particularly troublesome to mitigate because UNIX tools inherently follow symbolic links. The only way to solve the problem is to avoid writing the actual files into public directories. You should do this as follows:

• Always create temporary directories with the mktemp command, then create your actual temporary files inside those directories. By doing this, you can set restrictive permissions on the directory that will prevent an attacker from deleting your files and replacing them.

  If you specify the -d flag, the mktemp command creates a new directory with the specified template, ensuring that a file or directory with that name does not already exist.

• Always use the umask command to specify initial permissions on files and directories when you create them.

For example:

#!/bin/sh

umask 0177

TMPDIR="$(mktemp -d /tmp/mytempfile.XXXXXX)"

echo "My password is secret!" > "$TMPDIR"/mypublicdata

...

PUBLICDATA="$(cat "$TMPDIR"/mypublicdata)"

echo "$PUBLICDATA" | nc 192.168.1.102 3333

Simple Example

Consider the following example:

read FOO

read BAR

if [ x$FOO = xfoo ] ; then

    echo $FOO

    eval $BAR

fi

This code has two security holes. Can you spot them?

• if [ x$FOO = xfoo ] ; then

  This statement allows for an injection attack on FOO.

  The attack:

  Pass “foo = xfoo -o x” as the value for FOO.

  Despite the fact that the value of FOO is not “foo”, the statement executes anyway. Depending on what this test does, this could potentially cause unexpected behavior.

  Mitigation:

  To fix this bug, change the if statement to read:

  if [ "$FOO" = "foo" ] ; then

• eval $BAR

  This is a no-no. Never run eval on data passed in by a user unless you have very, very carefully sanitized it (and if possible, use a whitelist to limit the allowed values).

  The attack:

  Pass a dangerous command for BAR.

  Mitigation:

  Just don’t do that.

Subtle Example

The following example is more subtle. Instead of running eval, it writes data to a script, but does so without protecting the values:

#!/bin/sh

read FOO

# ...

echo ls $FOO >> myscript.sh

# ...

chmod a+x myscript.sh

./myscript.sh

The attack:

Pass the value “; rm randomfile” to cause this script to delete a file.

The Wrong Mitigation:

You might be tempted to fix this bug by changing the echo and execution lines to read:

echo ls "\"$FOO\"" >> myscript.sh

export FOO

However, this still does not solve the problem because FOO is expanded immediately, which means that if the value of FOO contains a quotation mark—for example, “";rm randomfile ; echo "”, you now have a different (but equally bad) security hole.

Correct Mitigation #1:

One way to fix this bug is to change the echo line to read:

echo ls "\"\$FOO\"" >> myscript.sh

This causes the variable FOO to be expanded when the script is executed. However, this works only if the variable FOO is exported, because otherwise the variable FOO would expand to nothing in the second script.

Correct Mitigation #2:

Another way to fix this bug is to change the echo line to read:

QUOTFOO="$(echo "$FOO" | sed "s/'/'\"'\"'/g")"

echo ls "'$QUOTFOO'" >> myscript.sh

By using single quotes around the string in the secondary script, the only character relevant to the shell is the single quote character. The sed command then replaces any single quote characters in the string with a closing single quote followed by a single quote wrapped in double quotes followed by an opening single quote.

Backwards Compatibility Example

The following example is not dangerous in modern shells, but is dangerous in older Bourne shells:

#!/bin/sh

read FOO

echo $FOO

The attack:

Pass the value “; rm randomfile” to cause this script to delete a file in older shells.

Most modern shells parse the statement prior to any variable substitution, and are thus unaffected by this attack. However, for proper security when your script is run on older systems (not to mention avoiding a syntax error if the filename contains spaces), you should still surround the variable with double quotes.

Mitigation:

To fix this bug, change the echo line to read:

echo "$FOO"

Examining File Permissions

UNIX permissions are visible to users in Terminal and in the Finder’s Get Info window. In Terminal, you can easily look at the permissions in a human-readable format by using the ls command as follows:

$ ls -ld filename dirname

drwxr-xr-x  2 username  groupname  68 Jun 16 13:40 dirname

-rw-r--r--  1 username  groupname   0 Jun 16 13:40 filename

The left character indicates whether the file system object is a file (-), directory (d), symbolic link (l), block (b) or character (c) special file, named pipe (p), or UNIX domain socket (s).

The next three characters show the Owner permissions, followed by the Group permissions, and finally, the Other permissions as listed in the following table:

The complete set of permissions is often expressed in octal, as defined by the bits in the table above. The first digit includes the sticky bit and setuid and setgid bits. If zero, you may omit it when passing the value to most commands. The remaining three digits contain the Owner (user), Group, and Other permissions, respectively.

For example, a file that is setuid and setgid, with read/write/execute Owner permissions and read/execute Group and Other permissions, the octal equivalent is 6755:

• The leading special permissions value is 6, which is the bitwise OR of setuid (4) and setgid (2).

• The Owner permission is 7, which is the bitwise OR of the read (4), write (2), and execute (1) bits.

• The Group and Other permissions are both 5, which is the bitwise OR of the read (4) and execute (1) permissions.

To show the UNIX permissions of a file, use the stat command as follows:

stat -f "%p" filename

Ignore all but the last four digits returned.

Changing File Ownership and Permissions

The ability to change file ownership and permissions is limited by the operating system for security and quota reasons. Users can:

• Change the permissions for any file that they own.

• Change the group for any file that they own to any group that they are a member of.

Non-root users cannot:

• Change permissions on files owned by anyone else.

• Change the group of a file to a group that they are not a member of.

• Change the owner of any file.

The root user can change permissions and ownership arbitrarily except when blocked by BSD file system flags.

With those restrictions in mind, the sections that follow describe how to change permissions and change user and group ownership of files and directories.

# Change the owner of a file or directory

sudo chown newowner filename_or_dirname

# Change the owner of a directory and everything in it recursively

sudo chown -R newowner dirname

# Change the group by itself

chown :newgroup filename_or_dirname

chgrp newgroup filename_or_dirname

# Change the group of a directory and everything in it recursively

chown -R :newgroup dirname

chgrp -R newgroup dirname

# Change the owner and the group

sudo chown newowner:newgroup filename_or_dirname

# Change the group of a directory and everything in it recursively

sudo chown -R newowner:newgroup dirname

chmod a+rw world_writable_file

chmod u+rwx,g-rwx,o-rwx filename

chmod u+rwx,go-rwx filename

chmod a-rwx,u+rwx filename

chmod g=r filename

chmod a+rx,ug+s filename

chmod a+rxs filename    # Note: o+s is ignored.

chmod 666 world_writable_file

chmod 0666 world_writable_file

chflags uchg filename # user flag

sudo chflags schg filename # system flag

chflags nouchg filename # user flag

sudo chflags noschg filename # system flag

username grant rightname

groupname grant rightname

username deny rightname

groupname deny rightname

chmod +a "_mysql deny read" filename

ls -le filename

chmod +a# 0 "_www deny read" filename

chmod -a "_mysql deny read" filename

chmod =a# 0 "_mdnsresponder deny read" filename

chmod +a "_www deny list,search,directory_inherit" dirname

Securing Temporary Files

Because the temporary directories in OS X and other UNIX-based operating systems are world-writable, you must take care to ensure that you are modifying the file you think you are modifying.

For example, the following code has two serious bugs:

if [ ! -f /tmp/mytempfile ] ; then

    # Race condition here

    touch /tmp/mytempfile

    chmod u=rw,og= /tmp/mytempfile

    # Missing error check here

    echo My secret password is omnibus > /tmp/mytempfile

fi

An application that happens to get the timing right can create a file called /tmp/mytempfile right after the script checks for its existence, wait for the script to write data into it, and subsequently steal the password. The chmod command would produce an error in this case, but because the script doesn’t check the result code, the error is moot.

To solve this problem, always use the mktemp command to create temporary files. The mktemp command creates files with initial permissions of 0600, and never returns an existing file. (Using mktemp also provides an easy way to obtain a known-unique filename, potentially avoiding unexpected behavior caused by temp file collisions.)

Detecting Unset Variables

By default, the Bourne shell treats unset variables as empty (unlike csh). If your script expects that unset variable to contain a value, this can lead to incorrect script execution and, depending on the script, may even result in a security hole. To guard against this, you can issue the following command:

set -u

With this flag set, if your script tries to use an empty variable, the shell prints an error message, and the entire script exits immediately with a nonzero exit status.

If desired, you can later restore the default behavior with the following command:

set +u

Checking Exit Status Automatically

For very simple scripts, checking the exit status of each command can be tedious. You can greatly simplify these scripts by instead issuing the following command:

set -e

With this flag set, if any simple command exits with a nonzero exit status, the shell terminates with that command’s exit status. A simple command is defined as a command that includes no pipes or lists, that is not executed as part of a control statement, and whose exit status is not inverted with an exclamation point.

If desired, you can later restore the default behavior with the following command:

set +e

Exporting Variables Automatically

It is not always necessary to export variables that your script uses internally. However, if a child process depends on the values of those variables, they must be exported. In some cases, failing to export a variable could even result in a security hole if it causes the child to grant a user access that he or she would otherwise not have. For example, if a CGI script running in a web server environment provides additional limits on what files a remote user can access, a bug in that script might give the user access to other files.

You can, if desired, tell the shell to automatically export any variable that your script sets by issuing the following command:

set -a

If desired, you can later restore the default behavior with the following command:

set +a

Retrieving the Exit Status of Piped Commands in BASH

The exit status of a series of commands connected by pipes is, by default, the exit status of the rightmost command. If you do not examine the output from the final command to ensure that it makes sense, this default behavior can potentially mask errors that might lead to security problems.

For example, consider the following code:

ls nonexistentfile | cat

echo $?

In the first command, even though the ls command fails, the cat command does not care whether it received any input or not, and thus exits with a zero exit status. As a result, the pipe’s exit status is zero. If it is critical to know whether the first command failed (for example, if it performs an operation with an important side effect, such as removing a file on disk), then this is potentially unsafe.

There are many ways that you can fix this problem. The most obvious fix is to store the results of the first command into a variable temporarily, check the result code of the first command, and then use echo to pipe the results to the second command. This technique is often less than ideal for commands that take a long time to execute or produce large amounts of output, however, because the second command does not receive any data until after the first command exits. The performance impact is particularly noticeable if the output of the final command is expected to be read by the user.

As an alternative, in BASH, you can issue the following command before issuing the commands above:

set -o pipefail

After issuing this command, the pipe’s exit status is provided by the rightmost command that failed with a nonzero exit status, or zero if every command in the chain of pipes exited successfully. In the earlier example, the final echo command would print the number 1 (the exit status of the ls command).

If desired, you can later restore the default behavior with the following command:

set +o pipefail

Sanitizing the Environment in BASH

For BASH shell scripts (or Bourne shell scripts running in BASH) that must run in a privileged environment (as the root user, for example), it is a good idea to tell the shell to not automatically execute any “run commands” files (.bashrc, .profile, and so on) that may contain alias commands that affect script execution, functions that may override commands in your script, or even malicious commands that an attacker wants your script to execute while running as the root user.

To sanitize the script’s environment in this way, you should change your script’s interpreter line to the following:

#!/bin/bash -p

In this mode, the scripts referenced by the ENV and BASH_ENV environment variables are not executed, shell functions are not inherited, and the SHELLOPTS environment variable is ignored.