| Attack Pattern ID | Pattern Abstraction: Standard 29 |
| Typical Severity | High |
| Description | Summary This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. The typical example is the file access. The attacker can leverage a file access race condition by "running the race", meaning that he would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the attacker could do something such as replace the file and cause an escalation of privilege. Attack Execution Flow The attacker explores to gauge what level of access he has. The attacker confirms access to a resource on the target host. The attacker confirms ability to modify the targeted resource. The attacker decides to leverage the race condition by "running the race", meaning that he would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the attacker can replace the resource and cause an escalation of privilege.
|
| Attack Prerequisites | A resource is access/modified concurrently by multiple processes. The attacker is able to modify resource. A race condition exists while accessing a resource. |
| Typical Likelihood of Exploit |
High
|
| Methods of Attack | - Time and State
- Modification of Resources
|
| Examples-Instances | Description The Net Direct client for Linux before 6.0.5 in Nortel Application Switch 2424, VPN 3050 and 3070, and SSL VPN Module 1000 extracts and executes files with insecure permissions, which allows local users to exploit a race condition to replace a world-writable file in /tmp/NetClient and cause another user to execute arbitrary code when attempting to execute this client, as demonstrated by replacing /tmp/NetClient/client. Related Vulnerability Description The following code illustrates a file that is accessed multiple times by name in a publicly accessible directory. A race condition exists between the accesses where an attacker can replace the file referenced by the name.
include <sys/types.h>
include <fcntl.h>
include <unistd.h>
define FILE "/tmp/myfile"
define UID 100
void test(char *str)
{
int fd;
fd = creat(FILE, 0644);
if(fd == -1)
return;
chown(FILE, UID, -1); /* BAD */
close(fd);
}
int main(int argc, char **argv)
{
char *userstr;
if(argc > 1) {
userstr = argv[1];
test(userstr);
}
return 0;
}
//Source : SAMATE.NIST.GOV : http://samate.nist.gov/SRD/view_testcase.php?login=Guest&;tID=1598 |
| Attacker Skill or Knowledge Required | Medium/High: This attack can get sophisticated since the attack has to occur within a short interval of time. |
| Probing Techniques | Vulnerability testing tool can be used to probe for race condition. The attacker may also look for temporary file creation. The attacker may try to replace them and take advantage of a race condition. |
| Solutions and Mitigations | Use safe libraries to access resources such as files. Be aware that improper use of access function calls such as chown(), tempfile(), chmod(), etc. can cause a race condition. Use synchronization to control the flow of execution. Use static analysis tools to find race conditions. Pay attention to concurrency problems related to the access of resources. |
| Attack Motivation-Consequences | - Data Modification
- Privilege Escalation
- Run Arbitrary Code
- Information Leakage
- Denial of Service
|
| Context Description | The window of time between when a file property is checked and when the file is used can be exploited to launch a privilege escalation attack.
File access race conditions, known as time-of-check, time-of-use (TOCTOU) race conditions, occur when:
1. The program checks a property of a file, referencing the file by name.
2. The program later performs a filesystem operation using the same filename and assumes that the previously-checked property still holds.
Example: The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable to the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.
if(!access(file,W_OK)) {
f = fopen(file,"w+");
operate(f);
...
}
else {
fprintf(stderr,"Unable to open file %s.\n",file);
}
The call to access()behaves as expected, and returns 0if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges.
This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.
The window of vulnerability for such an attack is the period of time between when the property is tested and when the file is used. Even if the use immediately follows the check, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.
|
| Related Weaknesses | | CWE-ID | Weakness Name | Weakness Relationship Type |
|---|
| 367 | Time-of-check Time-of-use Race Condition | Targeted | | 368 | Context Switching Race Condition | Secondary | | 366 | Race Condition within a Thread | Secondary | | 370 | Race Condition in Checking for Certificate Revocation | Secondary | | 362 | Race Condition | Secondary |
|
| Related Attack Patterns | | ID | Name | Relationship Type | Relationship Description |
|---|
| 26 | Leveraging Race Conditions | More Detailed | | | 27 | Leveraging Race Conditions via Symbolic Links | More Abstract | |
|
| Related Security Principles | |
| Purpose | Exploitation |
| CIA Impact | | Confidentiality Impact | Integrity Impact | Availability Impact |
|---|
| High | High | Low |
|
| Technical Context | | Architectural Paradigm | Framework | Platform | Language |
|---|
| All | All | All | All |
|
| References | J. Viega and G. McGraw. Building Secure Software. Addison-Wesley, 2002. CWE – Input Validation |
| Source | | Submission(s) |
|---|
| Submitter | Organization | Date | Comment |
|---|
| Eric Dalci | Cigital, Inc | 2007-01-25 | |
| Modification(s) |
|---|
| Modifier | Organization | Date | Comment |
|---|
| Sean Barnum | Cigital, Inc | 2007-03-07 | Review and revise | | Richard Struse | VOXEM, Inc | 2007-03-26 | Review and feedback leading to changes in Name, Attack Flow, Attack Prerequisites and Related Attack Patterns | | Sean Barnum | Cigital, Inc | 2007-04-13 | Modified pattern content according to review and feedback |
|
