Race Condition in Time of Check, Time of Use

From Guidance Share

Jump to: navigation, search

Contents

Description

Time-of-check, time-of-use race conditions occur when between the time in which a given resource is checked, and the time that resource is used, a change occurs in the resource to invalidate the results of the check.

Applies To

  • Languages: Any
  • Platforms: All

Example

The following example shows a potential time of check, time of use problem:

struct stat *sb;
..
lstat(“...”,sb);
// it has not been updated since the last time it was read
printf(“stated file\n”);
if (sb->st_mtimespec==...)
print(“Now updating things\n”);
updateThings();
}

Potentially the file could have been updated between the time of the check and the lstat, especially since the printf has latency.

Impact

  • Access control: The attacker can gain access to otherwise unauthorized resources.
  • Authorization: Race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question.
  • Integrity: The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user.
  • Accountability: If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur.
  • Non-repudiation: In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files.

Vulnerabilities

  • Failure to lock resources so that they may not be modified between time of check and time of use.

Countermeasures

  • Design: Ensure that some environmental locking mechanism can be used to protect resources effectively.
  • Implementation: Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.

Vulnerability Patterns

How Tos

Personal tools