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

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: Standard
Status: Draft
Completeness: Complete
+ 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

Explore
  1. The attacker explores to gauge what level of access he has.

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

Exploit
  1. 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 Severity

High

+ Typical Likelihood of Exploit

Likelihood: 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 Vulnerabilities

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.

(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)
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;
}

[R.29.3]

+ 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

Description

Vulnerability testing tool can be used to probe for race condition.

Description

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
Integrity
Modify memory
Confidentiality
Access_Control
Authorization
Gain privileges / assume identity
Confidentiality
Integrity
Availability
Alter execution logic
Confidentiality
Read application data
Availability
DoS: resource consumption (CPU)
Denial of Service
+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: HighIntegrity Impact: HighAvailability Impact: Low
+ Technical Context
Architectural Paradigms
All
Frameworks
All
Platforms
All
Languages
All
+ 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
Submissions
SubmitterOrganizationDateComments
Eric DalciCigital, Inc2007-01-25
Modifications
ModifierOrganizationDateCommentsSource
Sean BarnumCigital, Inc2007-03-07Review and revise
Richard StruseVOXEM, Inc2007-03-26Review and feedback leading to changes in Name, Attack Flow, Attack Prerequisites and Related Attack Patterns
Sean BarnumCigital, Inc2007-04-13Modified pattern content according to review and feedback
CAPEC Content TeamThe MITRE Corporation2013-06-21Updated Code_Example_Language and Example-Instance_DescriptionInternal
CAPEC Content TeamThe MITRE Corporation2013-12-18Updated Related_Attack_PatternsInternal
CAPEC Content TeamThe MITRE Corporation2014-02-06Updated Attack_PhasesInternal

Page Last Updated: April 10, 2014