Home > CAPEC List > CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions (Version 2.11)  

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
Definition in a New Window Definition in a New Window
Attack Pattern ID: 29
Abstraction: Detailed
Status: Draft
Completeness: Complete
Presentation Filter:
+ 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. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they 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 adversary could replace or modify the file, causing the application to behave unexpectedly.

+ Attack Steps
  1. The adversary explores to gauge what level of access he has.

  1. The adversary confirms access to a resource on the target host. The adversary confirms ability to modify the targeted resource.

  1. The adversary 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 adversary can replace the resource and cause an escalation of privilege.

+ Attack Prerequisites
  • A resource is access/modified concurrently by multiple processes.

  • The adversary is able to modify resource.

  • A race condition exists while accessing a resource.

+ Typical Severity


+ Typical Likelihood of Exploit

Likelihood: High

+ Methods of Attack
  • Time and State
  • Modification of Resources
+ Examples-Instances


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 Vulnerabilities


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 adversary can replace the file referenced by the name.

(Bad Code)
Example Language:
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)
chown(FILE, UID, -1); /* BAD */

int main(int argc, char **argv)
char *userstr;
if(argc > 1) {
userstr = argv[1];
return 0;


+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

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
ScopeTechnical ImpactNote
Modify memory
Gain privileges / assume identity
Alter execution logic
Read application data
DoS: resource consumption (CPU)
Denial of Service
+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
+ References
[R.29.1] [REF-29] J. Viega and G. McGraw. "Building Secure Software". Addison-Wesley. 2002.
[R.29.2] [REF-3] "Common Weakness Enumeration (CWE)". CWE-20 - Input Validation. Draft. The MITRE Corporation. 2007. <http://cwe.mitre.org/data/definitions/20.html>.
[R.29.3] [REF-41] Fortify Software. "SAMATE - Software Assurance Metrics And Tool Evaluation". Test Case ID 1598. National Institute of Standards and Technology (NIST). 2006-06-22. <http://samate.nist.gov/SRD/view_testcase.php?tID=1598>.
+ Content History
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
CAPEC Content TeamThe MITRE Corporation2017-01-09Updated Related_Attack_PatternsInternal
CAPEC Content TeamThe MITRE Corporation2017-08-04Updated Attack_Phases, Attack_Prerequisites, Description Summary, Examples-InstancesInternal

More information is available — Please select a different filter.
Page Last Updated or Reviewed: July 31, 2017