Race Condition A Detailed Exploration

Learn about race conditions, their types, exploitation techniques, and mitigation strategies.

Posted Jun 16, 2025 Updated Aug 3, 2025

By Omar Samy

13 min read

Race Condition A Detailed Exploration

if you think you know race condition think again!!

السلام عليكم ورحمة الله وبركاته

don’t forget to pray for our brothers in Gaza and Sudan

in this article I am going to take you in a journey of race condition in detail

Understanding Race Conditions: A Deep Dive into Concurrent Vulnerabilities

Race conditions are a critical class of vulnerabilities in modern computing, stemming from the unpredictable timing of concurrent operations. This article will guide you through what race conditions are, how they manifest, and crucially, how to defend against them.

1. Perquisites You Should Know First

Before diving into race conditions, let’s establish some foundational terms:

Process: Your computer allocates dedicated internal memory to run applications. Each independent application execution, like a web browser, is recognized by your system as a process.
Thread: Threads are individual units of execution within a process, handling specific features or tasks. For instance, a browser process might have threads for input handling, internet searching, and output rendering. Threads share the same memory space allocated to their parent process.
Multithreading: This refers to the simultaneous execution of multiple threads. Even simple activities, such as opening a browser, require the system to process numerous threads concurrently.
Multi-Processing: This involves the parallel execution of multiple processes. This technique enhances system and application speed by distributing tasks across various processors.

2. What is a Race Condition and How It Works

A race condition occurs when multiple threads or processes concurrently access and modify shared data, and the final outcome depends on the unpredictable timing or sequence of their execution. In such a scenario, these threads are “racing” each other to access and change the data. Without proper synchronization, this concurrency can lead to unexpected and often erroneous results, creating vulnerabilities that attackers can exploit.

Imagine a bank system where customers frequently transfer money between accounts. The system tracks account balances, which can be accessed and modified by multiple users simultaneously. A race condition could arise if User A attempts to transfer funds from Account X to Account Y, while User B concurrently initiates a transfer from the same Account X to Account Y.

To illustrate this in a practical coding context, consider the following Django example:

  
# Vulnerable Django View
def my_view(request):
    obj = MyModel.objects.get(pk=1)
    obj.field += 1
    obj.save()
    return HttpResponse("Updated successfully!")

In the code above, the Django view my_view retrieves an object from the database, modifies a field, and then saves it back. If two users simultaneously send a request to this view, they might both retrieve the object before either has a chance to save their modifications. User A retrieves the object, then User B retrieves it. Next, User A saves their changes, followed by User B saving theirs. The critical issue here is that User A’s changes are lost, as they are overwritten by User B’s subsequent save.

This problem leads to inconsistent data and unexpected behavior. The system is not properly handling the case where concurrent inputs (in this instance, HTTP requests) do not arrive in the expected order, leading to a loss of data integrity.

Note: Remember this example, as we’ll mitigate it later.

3. Race Condition Types

Race conditions manifest in various forms, each with unique characteristics:

3.1. Time-of-Check to Time-of-Use (TOCTOU) Flaw

This type involves a change in the system’s state between the moment a condition is checked and the moment it’s actually used.

Example: File Access Race Condition Consider a scenario where a file’s permissions are checked before a user is allowed to access it. An attacker can manipulate this by changing permissions between the security check and the file’s actual usage, potentially gaining unauthorized access or privilege escalation.

3.2. Limit Overrun Race Condition

This type allows attackers to bypass or surpass set limits by exploiting timing vulnerabilities, often by submitting multiple requests concurrently.

Example: Coupon Code Redemption In an e-commerce platform, a user applies a one-time discount coupon during checkout. By cleverly timing multiple attempts (e.g., sending rapid, concurrent requests), the user could repeatedly reuse the code within a small window, bypassing the intended single-use restriction.

A famous example of this type was discovered by security researcher Egor Homakov, who found a race condition that resulted in essentially unlimited money on Starbucks gift cards.

Starbucks.com had personal accounts where users could add gift cards, check balances, and transfer money between them. The money transfer process from card1 to card2 was stateful:

POST /step1 amount=1&from=wallet1&to=wallet2 saved these values in the session.
POST /step2 confirm actually transferred the money and cleared the session.

This “protection” was bypassed by using the same account from two different browsers (with different session cookies).

Consider having two cards, each with $5.

Pseudo-code for the exploit:

// Initial state: wallet1 = $5, wallet2 = $5

// Browser 1 (Session A)
1. POST /step1 amount=5&from=wallet1&to=wallet2
   // Server saves: {sessionA: {amount: 5, from: wallet1, to: wallet2}}

// Browser 2 (Session B) - CONCURRENTLY
2. POST /step1 amount=5&from=wallet1&to=wallet2
   // Server saves: {sessionB: {amount: 5, from: wallet1, to: wallet2}}

// Browser 1 (Session A) - immediately after step 1
3. POST /step2 confirm
   // Server processes transfer for Session A: wallet1 -= $5, wallet2 += $5
   // wallet1 = $0, wallet2 = $10
   // Session A data cleared

// Browser 2 (Session B) - immediately after step 2, while Session A is processing or just finished
4. POST /step2 confirm
   // Server processes transfer for Session B (reads wallet1 as $0): wallet1 -= $5 (to -$5), wallet2 += $5
   // wallet1 = -$5, wallet2 = $15
   // Session B data cleared

// The exploit results in: wallet1 = -$5 (debt), wallet2 = $15. Total money is now $10 + $15 = $25 (initial was $10).
// The user effectively duplicated money.

The example shows how concurrent requests, even with session clearing, could lead to unexpected behavior and monetary gain.

3.3. Ordering Race Condition

Instances where the execution order of processes significantly impacts the outcome, often due to non-atomic multi-step operations that are not properly synchronized.

Example: Multi-threaded Payment System In a payment processing system, if two transactions attempt to withdraw the same amount from an account simultaneously, the order of execution may lead to an overdraft due to insufficient funds not being checked or updated atomically.

3.4. Deadlocks and Livelocks

These conditions halt progress or lead to continual resource contention, often due to improper resource locking.

Deadlock: In a database system, two processes attempt to access the same resources but in a different order, resulting in both processes waiting for resources that the other holds. This leads to a system halt where neither process can proceed.
Livelock: Processes continually change their state in response to other processes, but without making any actual progress. They are actively executing but unable to complete their tasks.

3.5. Priority Inversion

This occurs when a lower-priority process inadvertently preempts a higher-priority one due to shared resource contention.

Example: Real-time Systems In real-time systems, a high-priority task waiting on a low-priority task to release a shared resource can result in significant delays, impacting critical operations.

3.6. Micro-Architectural Race Conditions

These are highly complex vulnerabilities specific to hardware-level operations, often exploited by advanced attackers with deep CPU architecture knowledge.

Example: Spectre and Meltdown Vulnerabilities These vulnerabilities exploit CPU performance optimizations, such as speculative execution, by manipulating timing discrepancies to allow unauthorized access to sensitive data stored in memory.

4. How to Exploit and Test Race Conditions

Testing for race conditions typically falls into two categories:

4.1. White Box Testing

The most effective way to test for race condition vulnerabilities is with access to the source code. This allows security professionals to meticulously review functions and identify logic that assumes synchronous actions without proper defensive programming techniques. It involves:

Code Review: Manually inspecting code for shared resources, non-atomic operations, and potential timing windows.
Static Analysis: Using tools that can identify potential concurrency issues in the code.

4.2. Black Box Testing

When you do not have access to the source code, testing for race conditions becomes trickier but is certainly not impossible. The core principles of identifying functions that modify shared resources still apply, though finding and testing them may be more challenging.

Common Black Box Strategies:

Concurrent Requests: Sending multiple identical requests simultaneously to sensitive endpoints (e.g., account updates, coupon redemptions, resource allocations).
Timed Delays: Introducing slight, controlled delays between requests to try and hit specific timing windows.
Focus on State-Changing Operations: Prioritize testing endpoints that involve financial transactions, user authentications, resource creations/deletions, or any operation that modifies shared data.

Tools for Black Box Testing:

Race-The-Web: This open-source tool (available on GitHub here) is designed to rapidly send concurrent requests, increasing the likelihood of triggering a race condition on performant web applications.
Burp Suite Intruder: While more versatile, Burp Suite’s Intruder can be configured to test for race conditions. By setting a high number of threads and using attack types like “Sniper” or “Cluster Bomb” with minimal payloads, you can send numerous requests concurrently.

Successfully exploiting a race condition can lead to severe consequences, including data corruption, unauthorized access, denial of service, or significant financial loss.

5. Defense and Mitigation

Preventing race conditions primarily revolves around ensuring atomicity (operations complete entirely or not at all) and sequential execution for critical sections of code or data.

5.1. Programming Languages: Implementing Locks

The most direct way to prevent race conditions at the application level is through locks. Locks ensure that only one thread can access a shared resource or execute a critical section of code at a time. Most modern programming languages provide built-in locking functionalities.

Python: threading.Lock
Go: sync.Mutex
Java: synchronized keyword, java.util.concurrent.locks.Lock

Let’s mitigate our earlier Django example, shall we?

  
from django.db import transaction
from django.http import HttpResponse, HttpResponseNotFound, HttpResponseServerError
from .models import MyModel # Assuming MyModel is defined in models.py

def my_view_mitigated(request):
    try:
        # Start an atomic transaction to ensure all operations are treated as a single unit.
        # select_for_update() locks the selected rows until the end of the transaction,
        # preventing other concurrent transactions from modifying them.
        with transaction.atomic():
            obj = MyModel.objects.select_for_update().get(pk=1)
            obj.field += 1
            obj.save()
            return HttpResponse("Updated successfully!")
    except MyModel.DoesNotExist:
        return HttpResponseNotFound("Object with pk=1 not found.")
    except Exception as e:
        # Log the error for debugging
        print(f"An error occurred: {e}")
        return HttpResponseServerError("An error occurred during the update.")

Explanation of the Mitigation:

transaction.atomic(): This context manager starts a database transaction. All database queries within this block are executed as a single, atomic unit. If any error occurs, all changes within the block are rolled back, ensuring data consistency.
select_for_update(): This crucial method locks the database rows retrieved until the current transaction is complete. Any other concurrent transactions attempting to modify these locked rows will be blocked until the current transaction finishes, effectively preventing race conditions by enforcing sequential access to the data.
Error Handling (try/except): The block ensures that the lock is properly managed even if an error occurs, preventing potential deadlocks or lingering locks.

This code should be thoroughly tested to confirm the race condition is resolved and that the locking mechanism works as expected without introducing new issues.

Databases play a crucial role in preventing race conditions, especially those compliant with ACID (Atomicity, Consistency, Isolation, Durability) properties.

Isolation Levels: The key ACID component for race synchronization is isolation. Databases offer various isolation levels:
- Serializable: This is the highest level of isolation, effectively forcing all transactions to occur sequentially. While it guarantees safety from race conditions within the database, it can significantly slow down operations and may lead to frequent deadlocks due to exclusive locks.
- Repeatable Read (e.g., in MySQL): This level offers a higher degree of safety than lower levels without the extreme performance overhead of serializable. It ensures that if you read a row multiple times within a transaction, you’ll always get the same result, but it doesn’t prevent “phantom reads” (new rows appearing from other transactions).
- Choosing the Right Level: Balancing security with performance is critical. For most applications, a lower but still robust isolation level (like “repeatable read”) might be a more practical choice, coupled with application-level locking for the most critical sections.
Inserts vs. Updates: Whenever possible, prefer inserts over updates in your SQL queries. Inserts typically have more built-in error protection in most database configurations, which can help prevent modifying a single database entry simultaneously and reduce the risk of race conditions on existing data.

File-level locking can also prevent race conditions when dealing with shared files:

System Calls: Operating systems provide system calls to enforce file locks. Examples include LockFile in Windows and flock or lockf in Unix-like systems. Most programming languages abstract these low-level calls into higher-level file handling functions.
Temporary Lock Files: Many applications, like Microsoft Word, create temporary “lock files” (e.g., ~myfile.lck) when a file is being accessed for writing. Other programs wanting to write to the same file check for the existence of this lock file before granting write access.

5.4. HTTP/Web Application-Specific Mitigations

While application-level locking is the most effective, other strategies can reduce the likelihood of race conditions in web applications:

CSRF Tokens: Implementing Cross-Site Request Forgery (CSRF) tokens can make it more difficult for attackers to automate the large number of concurrent requests needed to trigger a race condition, as each valid request would require a unique token.
Server-Side Request Queues: For extremely high-traffic or highly sensitive operations, a server-side request queue can be implemented. This processes requests for a specific critical action one by one, ensuring strict sequential execution and eliminating concurrency for that particular operation.

Race Conditions in Synchronous Environments?

It’s a common misconception that languages without native asynchronous or multi-threading concepts, like PHP, are immune to race conditions. However, PHP applications typically run on asynchronous, multi-threaded platforms (like Nginx or Apache). While PHP itself executes functions sequentially, the underlying platform can initiate many PHP processes or requests simultaneously. If these concurrent PHP executions attempt to access or modify a shared resource outside their scope (e.g., a database entry, a file), a race condition can still occur.

Conclusion

As with all security mitigations, achieving complete protection against race conditions often involves balancing security requirements with business needs and performance considerations. The most effective defense primarily relies on robust locking mechanisms at the application and database levels, ensuring that critical operations on shared resources are handled atomically and sequentially. Proactive identification and mitigation of race conditions are paramount for building secure, reliable, and high-integrity applications in today’s concurrent computing landscape.

Resources

thanks for reading. If you enjoyed this write-up, feel free to follow me on Twitter

research

This post is licensed under CC BY 4.0 by the author.