Building Secure Software
Chapter 9
Race Conditions
Race Conditions
What is it?
• A race condition occurs when an assumption needs to
hold true for a period of time, but actually may not.
• Whether it is true is a matter of timing.
• In every race condition there is a window of vulnerability
or a period of time when the assumption leads to
incorrect behavior.
• When the assumption is broken, leading to unexpected
behavior, then the race condition has been exploited.
• See example of Bob and Alice on the elevator p. 210.
Each assume that the other one is in the other place and
is staying put and both take the elevator (this is a race
condition).
Race Conditions
What is it?
• In computer programs, windows of vulnerability can be
large, but often are small.
• A program with code to set a variable X and immediately
print its value could have a race condition since the
program could be multi-threaded.
• Two processes P1, P2 could hit the code to set X at the
same time. If P1 sets X=1 and P2 sets X=2 before P1
prints X, P1 has an invalid value of X.
• An attacker with control over machine resources can
increase the odds of exploiting a race condition by
slowing down the machine.
• Race conditions with security implications generally only
need to be exploited once. Automated code can find the
race condition by just waiting long enough.
Race Conditions
What is it?
• One way to fix a race condition is to reduce the
window of vulnerability to zero time. Do this by
making sure that all assumptions hold for
however long they need to hold.
• Create Critical Sections in code which only allows
one process at a time to access the critical
section code.
• Critical sections are defined by placing locking
primitives in front and behind the block of code.
• If not done correctly, the potential for deadlocks
and inefficiencies exist.
Race Conditions
What is it?
• Race conditions are possible if two or more
processes are running and one depends on the
other.
• In the time interval between events, an attacker
may be able to force something to happen,
changing the behavior of the system in ways not
anticipated.
• The attacker must have a security-critical
context and explicit attention to timing and
knowledge of the assumptions.
• The attacker “races” to invalidate assumptions
about the system that the programmer set in
the interval between operations.
Race Conditions
Time-of-Check, Time-of-Use
• Any time multiple threads of execution exist, race
conditions are possible.
• Multiple processes on a single machine can have race
conditions between them when they operate on data
that may be shared.
• The most common type of data shared are files which
are vulnerable to security-critical race conditions.
• UNIX is primarily vulnerable to race conditions involving
files due to the need for local access. Windows is less
vulnerable as it uses handles instead of continually
referring to files as symbolic strings.
Race Conditions
Time-of-Check, Time-of-Use
• Time-of-Check, time-of-use flaws (TOCTOU) involve a
check on some property of the file that precedes the use
of that file. The check needs to be valid at the time of
use for proper behavior, but may not be.
• Suppose a program running setuid root is asked to write
a file owned by the user running the program. The root
user can write to any file it wants, so the program must
take care not to write to anything unless the actual user
has permission to do so.
• Good Solution: Set EUID to the UID running the
program.
Race Conditions
Time-of-Check, Time-of-Use
• Poor Solution: Use the access call (see p. 215)
• The window of vulnerability here is the time it takes to
call fopen and have it open a file, after having called
access().
• The attacker creates a dummy file with his permissions,
and then creates a symbolic link to it:
$ touch dummy
$ ln –s dummy pointer
$
The attacker tells the program to open the file named
pointer and execute within the window of vulnerability:
$ rm pointer; ln –s /etc/passwd pointer
If it works, the program will overwrite the system
password file.
Race Conditions
Time-of-Check, Time-of-Use
• To exploit a file system race condition, the
following should be true:
(1) the attacker must have access to the local
machine, legitimate or not.
(2) the program with the race condition needs to
running with an EUID of root.
(3) the program must have this EUID for the
period of time of the race condition.
(4) Item (3) must exist so that the attacker will
be able to obtain root privileges.
(5) Without root privileges there would be no
race conditions.
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
Time-of-Check, Time-of-Use
Race Conditions
TOCTOU/Secure File Access
Race Conditions
Secure File Access
Race Conditions
Secure File Access
Race Conditions
Secure File Access
Race Conditions
Secure File Access
Race Conditions
Secure File Access
Race Conditions
Secure File Access
• Once a directory is created and not under
control of an attacker, it is usually filled with
files. Open files using a locking technique.
• Deleting a file can only occur securely if the
secure directory approach is used. This is true as
the OS removes a file using unlink() call by a
filename not file descriptor or file pointer
(vulnerable to a race condition).
• If the directory is secure, unlink() is safe as an
attacker can not create a symbolic link.
Race Conditions
Secure File Access
• Sometimes we need to protect the data in
deleted files.
• Deleted files are deleted by removing
pointers to the file. The file is still located
on the disk.
• There are many ways to make the data
useless using overwrite schemes.
Race Conditions
Temporary Files
• Temporary files are susceptible to the same potential problems that
regular files are, as attackers can guess the filenames.
• Strategy for creating a secure temporary file:
(1) Pick a prefix for the filename.
(2) Generate at least 64 bits of high-quality randomness from a
cryptographically secure source (chapter 10).
(3) Base64 encode the random bits (chapter 11)
(4) Concatenate the prefix with the encoded random data.
(5) Set umask (use 0066)
(6) Use fopen() to create the file.
(7) Delete file using unlink().
(8) Perform reads, writes, and seeks on the file as necessary.
(9) Close the file. Never close and reopen the file if it exists in a
directory with a potential race condition.
Race Conditions
File Locking
• Appropriate file locking can prevent race
conditions.
• OS do not require file locking.
• To prevent circumventing locking conventions,
make sure files are in a directory that cannot be
accessed by a potential attacker.
• To perform file locking: Use open() call, and
pass in the O_EXCL flag. The file can not be
opened if the file is in use.
• Do not use open() for file locking on all systems.
• If locking and unlocking are not done right, we
could get a deadlock situation.
Race Conditions
Other Race Conditions
• Security-critical race conditions occur in
other kinds of complex systems as well as
in file accesses.
• We encounter race conditions whenever
there are small windows of opportunity for
attackers to connect to databases or
servers.