What Is a Race Condition?

In any computing system, there are some tasks that need to be completed in a specific order. For example, before allowing someone to log in, a security system first receives their username and password and then checks it against a database before allowing access. Attackers can exploit this fact by interfering with processes to access secure areas and content in what's known as a race condition attack.

What Is a Race Condition Vulnerability?

Race condition attacks (also called Time of Check to Time of Use, or TOCTTOU attacks) take advantage of the need that computing systems must execute some tasks in a specific sequence. In any such sequence, there is a small period of time when the system has carried out the first task but not started on the second. If this period is long enough or the attacker is lucky and knowledgeable, a race condition vulnerability exists where an attacker can trick the system into carrying out unauthorized actions in addition to its normal processes.

There are two main ways this attack is carried out:

• Interference by an untrusted process - The attacker inserts a piece of code in between the steps of a secure process.
• Interference by a trusted process - The attacker exploits two different processes that share some state in common.

If you have a situation you think might be a race condition vulnerability, why not ask a qualified application security expert in our Veracode community? With thousands of expert users, it's a fantastic resource for any developer.

Rates of Race Condition Flaws in Software

Our analysis shows that most race condition flaws in software are race conditions within the same thread. Race condition vulnerabilities where attackers gain access to an alternate channel during a check, as well as TOCTTOU vulnerabilities, are less common types.

What Happens During a Race Condition Attack?

Race conditions can be found in many common attack vectors, including web applications, file systems, and networking environments. The good news is that, because they rely on attackers exploiting a system's process during a very short window of time, race conditions are somewhat rare. Most attackers will instead focus on easier types of attack, such as SQL injection vulnerabilities.

All the same, race condition attacks can lead to serious leaks and grant attackers complete access to secured systems, confidential data, and other information they shouldn't be able to view. Just a few of the types of systems that can be targeted with this kind of attack are access control list (ACL), a payroll or human resources database, a transactional system, a financial ledger, or any other data repository.

Anatomy of a Race Condition Security Flaw

Almost all programs and web applications today use what is called "multi-threaded" processing, where they are capable of executing multiple actions at once. Although this allows applications to be significantly faster, it does introduce the potential for errors if more than one process (or "thread") tries to access the same data at the same time.

For example, when a SQL system performs an update to a database, it creates a temporary file during the update process. It's this temporary file that eventually replaces the data in the database. With a well-timed attack, malicious users can replace the temporary file for a SQL update of an administrative access table with one of their own, granting themselves administrator privileges to the system.

Impact of a Race Condition Attack

As with most security breaches, a successful race condition attack can grant attackers access to secured areas of an application. In the example above, once the attacker replaces the database update with their own set of data, they will be able to log in as an administrator. Other possibilities include manipulating API calls, tricking a central server into executing the same action multiple times despite it not being valid after the first time. Attackers in Nevada used this technique to steal more than $1 million from Citibank ATMs, overwhelming the system with multiple nearly identical requests at once.

Race Condition Flaw Examples

There are many examples of race condition flaws in real life. Older browser versions especially can be vulnerable to race conditions.

In versions of Firefox older than 2.0.0.10, a race condition flaw in the window.location property allows attackers to spoof HTTP headers and bypass some types of security. Some older versions of Internet Explorer are similarly vulnerable, with attackers being able to use an exploit similar to cross-site scripting to execute arbitrary code or carry out a denial-of-service attack.

Here’s another example of a race condition vulnerability :(

/* vulp.c */

#include 

#include

#define DELAY 10000

int main()

{

char * fn = "/tmp/XYZ";

char buffer[60];

FILE *fp;

long int i;

/* get user input */

scanf("%50s", buffer );

if(!access(fn, W_OK)){

/* simulating delay */

Laboratory for Computer Security Education 2

for (i=0; i < DELAY; i++){

int a = iˆ2;

}

fp = fopen(fn, "a+");

fwrite("\n", sizeof(char), 1, fp);

fwrite(buffer, sizeof(char), strlen(buffer), fp);

fclose(fp);

}

else printf("No permission \n");

 

This example was created by Wenliang Du at Syracuse University. It is part of a Set-UID program (owned by root). The example appends a string of user input to the end of a temporary file /tmp/XYZ. Since the code uses the root privilege, it checks whether the user actually has access permission for the file /tmp/XYZ. In fact, this is the specific purpose of the access() call. Once the program has verified that the intended user has the privilege, the program opens the file and writes the user input into the file.

At first glance, the program appears to be sound. However, it contains a race condition vulnerability. Due to the window (the simulated delay) between the check (access) and the use (fopen), there is a possibility that the file used by access is different from the file used by fopen, despite the fact that they share the file name /tmp/XYZ. A malicious attacker who can make /tmp/XYZ a symbolic link pointing to /etc/shadow can cause the user input to be appended to /etc/shadow. The program runs with the root privilege and so it can overwrite any file.

Preventing Damage and Remediating Code Are Critical

It’s critical to scan and review code for race condition vulnerabilities. This includes the use of static analysis. Overall, SANS Technology Institute points out: “Careful programming and good administration practices usually can clear [race condition vulnerabilities] up, but you've got to find them first.” This means educating development teams about the risks of race condition attacks and how to prevent them.

Why Educated Developers Are Critical to Information Security

To ensure the safety of their customers and data, development teams today must build application security into every step of the application development process. By using tools such as static code scans, penetration testing, and other security checks, developers can find and correct race condition flaws before they can cause harm. In addition to the right tools, developers need knowledge to succeed in today's development environment. Veracode offers a variety of eLearning solutions, including self-paced classes and expert-led workshops, to help any development team learn the basics of application security.

Find and Remove Face Condition Flaws With Veracode

Our dynamic analysis scan checks web applications for flaws as they run in production or sandbox environments. This live testing can detect vulnerabilities that can't easily be found with pre-launch security scans.

In addition, Veracode's static analysis scan can help developers detect race condition flaws and other vulnerabilities before launch. Instead of requiring access to source code, our platform scans the binary (or executable) code of a program, allowing it to quickly and effectively find flaws in third-party code as well.

Veracode's powerful cloud-based platform quickly and accurately detects many types of security vulnerabilities, including race condition flaws. Rather than just detecting and explaining basic fixes for specific types of errors, Veracode provides contextual guidance that educates developers about secure coding practices right in the development workflow and environment they're used to using. Download our free secure coding handbook for an introduction to best practices, or contact us today to schedule a demo of our platform.