Download
1 / 31
330 likes | 499 Views
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.
E N D
Building Secure Software Chapter 9 Race Conditions
Race ConditionsWhat 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 ConditionsWhat 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 ConditionsWhat 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 ConditionsWhat 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 ConditionsTime-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 ConditionsTime-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 ConditionsTime-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 ConditionsTime-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 ConditionsSecure 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 ConditionsSecure 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 ConditionsTemporary 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 ConditionsFile 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 ConditionsOther 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.
