CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

Description

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

A race condition occurs within concurrent environments, and it is effectively a property of a code sequence. Depending on the context, a code sequence may be in the form of a function call, a small number of instructions, a series of program invocations, etc. A race condition violates these properties, which are closely related: A race condition exists when an "interfering code sequence" can still access the shared resource, violating exclusivity. The interfering code sequence could be "trusted" or "untrusted." A trusted interfering code sequence occurs within the product; it cannot be modified by the attacker, and it can only be invoked indirectly. An untrusted interfering code sequence can be authored directly by the attacker, and typically it is external to the vulnerable product.

Potential Impact

Demonstrative Examples

$transfer_amount = GetTransferAmount();$balance = GetBalanceFromDatabase();
                     if ($transfer_amount < 0) {FatalError("Bad Transfer Amount");}$newbalance = $balance - $transfer_amount;if (($balance - $transfer_amount) < 0) {FatalError("Insufficient Funds");}SendNewBalanceToDatabase($newbalance);NotifyUser("Transfer of $transfer_amount succeeded.");NotifyUser("New balance: $newbalance");

In the following pseudocode, the attacker makes two simultaneous calls of the program, CALLER-1 and CALLER-2. Both callers are for the same user account.CALLER-1 (the attacker) is associated with PROGRAM-1 (the instance that handles CALLER-1). CALLER-2 is associated with PROGRAM-2.CALLER-1 makes a transfer request of 80.00.PROGRAM-1 calls GetBalanceFromDatabase and sets $balance to 100.00PROGRAM-1 calculates $newbalance as 20.00, then calls SendNewBalanceToDatabase().Due to high server load, the PROGRAM-1 call to SendNewBalanceToDatabase() encounters a delay.CALLER-2 makes a transfer request of 1.00.PROGRAM-2 calls GetBalanceFromDatabase() and sets $balance to 100.00. This happens because the previous PROGRAM-1 request was not processed yet.PROGRAM-2 determines the new balance as 99.00.After the initial delay, PROGRAM-1 commits its balance to the database, setting it to 20.00.PROGRAM-2 sends a request to update the database, setting the balance to 99.00

void f(pthread_mutex_t *mutex) {
                        pthread_mutex_lock(mutex);
                           
                           /* access shared resource */
                           
                           
                           pthread_mutex_unlock(mutex);
                     }

int f(pthread_mutex_t *mutex) {
                        int result;
                           result = pthread_mutex_lock(mutex);if (0 != result)return result;
                           
                           
                           /* access shared resource */
                           
                           
                           return pthread_mutex_unlock(mutex);
                     }

Mitigations & Prevention

Detection Methods

• Black Box — Black box methods may be able to identify evidence of race conditions via methods such as multiple simultaneous connections, which may cause the software to become instable or crash. However, race conditions with very narrow timing windows would not be detectable.
• White Box — Common idioms are detectable in white box analysis, such as time-of-check-time-of-use (TOCTOU) file operations (CWE-367), or double-checked locking (CWE-609).
• Automated Dynamic Analysis Moderate — This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash
• Automated Static Analysis - Binary or Bytecode High — According to SOAR [REF-1479], the following detection techniques may be useful:
• Dynamic Analysis with Automated Results Interpretation SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
• Dynamic Analysis with Manual Results Interpretation High — According to SOAR [REF-1479], the following detection techniques may be useful:

Real-World CVE Examples

Showing 15 of 22 observed examples.

Related Weaknesses

Taxonomy Mappings

• PLOVER: — Race Conditions
• The CERT Oracle Secure Coding Standard for Java (2011): VNA03-J — Do not assume that a group of calls to independently atomic methods is atomic