CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition

The weakness occurs when a program relies on the state or identity observed at check time and later performs an operation without ensuring that the resource is still the checked object in the checked state. During this interval, another process, thread, or actor able to influence the resource can change a file, memory, variable, or other shared resource. The check may therefore indicate a safe condition while the actual operation affects a different resource or one in an unauthorized state.

This is a race condition introduced during implementation when a resource's state or identity changes after a check and before use. It is particularly relevant to shared resources such as files, memory, and variables in multithreaded programs, and becomes security-relevant when an attacker can influence the resource during that interval. Common names include TOCTTOU and TOCCTOU; the latter is generally treated as a misspelling of the former.

• Integrity and access control: An attacker may obtain access to resources that should be unauthorized, including read or write access to files, directories, application data, or memory, and may alter execution logic or create an unexpected state.
• Resource manipulation: The affected resource, or other resources reached through it, may be changed in undesirable ways. The product may also perform invalid actions when the resource is in an unexpected state.
• Non-repudiation and activity concealment: An operation performed through this weakness may avoid expected logging. In some cases, an attacker may delete files they could not otherwise access, including log files.

• Avoid a separate pre-use check where possible. Removing the check can avoid the false sense of security it provides, although it does not by itself guarantee that the resource's state and identity remain assured during the operation.
• Control privilege context for owned files. When the altered file is owned by the current user and group, set the effective group and user identities to those of the current user and group when executing the statement.
• Limit interleaving. Restrict how operations on files are interleaved across processes.
• Reduce the check-to-use interval when atomicity is unavailable. If multiple processes or threads must share the resource, minimize the CPU time between checking and using it. This only makes an attack more difficult and does not fix the underlying race.
• Verify after use. Recheck the resource after the use call to confirm that the action was performed appropriately.
• Provide environmental locking. Ensure that an effective locking mechanism is available to protect shared resources.
• Lock before checking. Acquire the lock before the check so that the resource checked is the same resource state used by the operation.

Automated static analysis, commonly called Static Application Security Testing (SAST), can detect some instances by analyzing source code or binary/compiled code without execution. It typically models data flow and control flow, then searches for potentially vulnerable patterns connecting input sources to sinks where data interacts with external components or lower layers such as the operating system; this approach cannot guarantee detection of every TOCTOU instance.

The official record lists the following representative examples, not an exhaustive set of vulnerabilities:

• CVE-2015-1743: a sandbox process allowed installation of untrusted browser add-ons by replacing a file after verification but before execution.
• CVE-2003-0813: a multithreaded race condition allowed two threads to process the same RPC request, causing a use-after-free, CWE-416, in one thread.
• CVE-2004-0594: a PHP flaw allowed remote attackers to execute arbitrary code by aborting execution before initialization of key data structures was complete.
• CVE-2008-2958 and CVE-2008-1570: TOCTOU race conditions allowed a protection mechanism intended to prevent symlink attacks to be bypassed.