Skip to content

Demystifying Race Condition Vulnerabilities

Demystifying Race Condition Vulnerabilities

Race conditions, a critical vulnerability, emerge when multiple processes or threads execute simultaneously within a software system. This blog seeks to offer a deep understanding of race conditions, and effective prevention strategies, all illustrated with practical examples

Myth – Do you think Race Condition Bugs often lead to DoS (denial of service)? In fact, race condition bugs can be used to execute arbitrary code, break cryptography, bypass authentication and so on . Following are the list of few CVEs with race condition issues.

Key examples of race condition vulnerability:

CVE-2023-24042Impact: Critical Data Exposure. A race condition in LightFTP through 2.2 allows an attacker to achieve path traversal via a malformed FTP request.
CVE-2022-4037Impact: Account Takeover. An issue has been discovered in GitLab CE/EE affecting all versions before 15.5.7, all versions starting from 15.6 before 15.6.4, all versions starting from 15.7 before 15.7.2. A race condition can lead to verified email forgery and takeover of third-party accounts when using GitLab as an OAuth provider.
CVE-2021-36532Impact: Remote Code Execution. Race condition vulnerability discovered in portfolioCMS 1.0 allows remote attackers to run arbitrary code via fileExt parameter to localhost/admin/uploads.php.
CVE-2020-1667Impact: Bypass Security Defenses. When DNS filtering is enabled on Juniper Networks Junos MX Series with one of the following cards MS-PIC, MS-MIC or MS-MPC, an incoming stream of packets processed by the Multiservices PIC Management Daemon (mspmand) process might be bypassed due to a race condition.This issue affects Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 18.3 versions prior to 18.3R3-S1; 18.4 versions prior to 18.4R3; 19.1 versions prior to 19.1R3; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3. This issue does not affect Juniper Networks Junos OS 17.4, 18.1, and 18.2.
CVE-2022-24800Impact: Remote Code Execution. October/System is the system module for October CMS, a self-hosted CMS platform based on the Laravel PHP Framework. Prior to versions 1.0.476, 1.1.12, and 2.2.15, when the developer allows the user to specify their own filename in the `fromData` method, an unauthenticated user can perform remote code execution (RCE) by exploiting a race condition in the temporary storage directory. This vulnerability affects plugins that expose the `OctoberRainDatabaseAttachFile::fromData` as a public interface and does not affect vanilla installations of October CMS since this method is not exposed or used by the system internally or externally.
CVE-2021-24377Impact: Remote Code Execution. The Autoptimize WordPress plugin before 2.7.8 attempts to remove potential malicious files from the extracted archive uploaded via the ‘Import Settings’ feature, however this is not sufficient to protect against RCE as a race condition can be achieved in between the moment the file is extracted on the disk but not yet removed. It is a bypass of CVE-2020-24948.

What Is  Race Condition

Imagine a scenario in a bank where customers frequently transfer money between their accounts. The system keeps track of account balances which can be accessed and modified by multiple users simultaneously.

In this context, a race condition occurs when two or more users attempt to transfer funds from one account to another at the same time. For instance, User A wants to move money from Account X to Account Y, and concurrently, User B also initiates a transfer from Account X to Account Y.

Generally, a race condition bug has following key prerequisits:

Critical Section: This is the crucial part of the system where shared resources, such as account balances, are accessed and modified. Multiple users can interact with these resources simultaneously.

Synchronization: The issue arises due to a lack of proper synchronization, which would usually prevent multiple processes from accessing the critical section at the same time. In this case, the system doesn’t manage these simultaneous transactions effectively.

Unpredictable Outcome: As User A and User B both attempt transfers from the same source account to the same destination account at the same time, the system fails to properly manage the transactions. This leads to an unpredictable state of the shared resource. Both transactions might proceed simultaneously, resulting in an erroneous perception that there is more money available in the account than there actually is. This misunderstanding could potentially lead to an overdraft situation.

This scenario illustrates how a race condition can lead to an unexpected and incorrect outcome due to the simultaneous, uncoordinated execution of multiple transactions.

Types of Race Conditions :

1. Time-of-Check to Time-of-Use (TOCTOU) Flaw:
This type involves a change in the system state between the moment a condition is checked and the moment it’s utilized.

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 check and the file’s actual usage.

2. Limit Overrun Race Condition:
This type allows the surpassing of set limits by exploiting timing vulnerabilities.

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

3. Ordering Race Condition:
Instances where the execution order of processes significantly impacts the outcome.

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 simultaneously.

4. Deadlocks and Livelocks:
These conditions halt progress or lead to continual resource contention.

Example: Database Deadlock
In a database system, two processes attempt to access the same resources but in a different order, leading to a deadlock scenario where both processes are waiting for resources that the other holds, resulting in a system halt.

5. Priority Inversion:
Lower priority processes preempt higher priority ones due to resource sharing.

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 delays, impacting critical operations.

6. Micro-Architectural Race Conditions:
These are specific to hardware-level operations.

Example: Spectre and Meltdown Vulnerabilities
These vulnerabilities exploit CPU performance optimizations, allowing unauthorized access to sensitive data by manipulating timing discrepancies in the processor’s speculative execution.

Impact of race conditions:

Exploitation of race conditions presents a critical and potentially devastating threat. These vulnerabilities offer malevolent actors pathways to gain unauthorized access, escalate privileges, or even provoke system-wide crashes. Let’s delve into some of the common scenarios where these vulnerabilities are exploited to wreak havoc:

Privilege Escalation:
By manipulating race conditions, attackers can cleverly maneuver systems to grant themselves elevated privileges. This deceptive action allows them to gain access levels beyond what is intended, thereby enabling a spectrum of malicious activities.

Data Corruption:
Simultaneous writes to shared resources can lead to a dire consequence: data corruption. This occurrence poses a substantial risk, potentially resulting in irreparable harm to crucial information.

Denial of Service (DoS):
Race conditions, when exploited skillfully, can cause system crashes. This leads to a denial of service for legitimate users, disrupting operations and service availability.

Information Leakage:
With precise timing and strategic exploitation of race conditions, attackers can stealthily extract sensitive information from shared resources before they are modified or encrypted. This clandestine action compromises data security and confidentiality.

-> Hackers Won't Wait For Your Next Pen Test: Know Automated Continuous Pen Test

Mitigations

Addressing race conditions effectively involves a comprehensive approach, combining meticulous coding reviews and Pentesting.

Testing and Code Review: Rigorous testing and peer code reviews play a pivotal role in identifying and rectifying potential vulnerabilities arising from race conditions. Thorough testing procedures, including stress testing and edge case scenarios, coupled with code reviews by experienced peers, offer a robust defense against race condition vulnerabilities.

Continuous Pentesting: Continuous pentesting is an approach to security testing that involves ongoing, regular assessments of an organization’s systems, applications, and networks to identify and address these vulnerabilities. Unlike traditional penetration testing, which is often conducted periodically, continuous pen testing is an ongoing and iterative process.Firecompass ensures continuous discovery and testing of external attack surfaces instead of the typical pen-test of 10-20% of their attack surface, leaving the peripheral assets untested for extended periods.

>>Click Here: To Get The Report Of Gartner Hype Cycle For Penetration Testing & Red Teaming

Conclusion

Race condition vulnerabilities present a tough problem in the complex field of cybersecurity. The necessity of taking proactive steps is highlighted by their potential to cause havoc on software systems and jeopardize security. Security experts and engineers may strengthen their systems against these attacks by knowing how race conditions work, how to exploit them, and how to mitigate the effects of them.

By: FireCompass Delivery Team – Komma Uma Maheswar reddy, Arnab Chattopadhayay , Amit Da, Joy Sen

About FireCompass:

FireCompass is a SaaS platform for Continuous Automated Pen Testing, Red Teaming  and External Attack Surface Management (EASM). FireCompass continuously indexes and monitors the deep, dark and surface webs using nation-state grade reconnaissance techniques. The platform automatically discovers an organization’s digital attack surface and launches multi-stage safe attacks, mimicking a real attacker, to help identify breach and attack paths that are otherwise missed out by conventional tools.

Feel free to get in touch with us to get a better view of your attack surface.

Important Resources:

Priyanka Aash