How to mitigate Race Conditions vulnerabilities

January 6, 2021 by

Howard Poston

Race condition vulnerabilities can exist when an application has multiple threads of execution that are running in parallel. This can occur either internal to an application (using multithreading) or if multiple different instances of an application are running at once.

Parallel processing is only an issue if an application’s threads of execution make unsafe use of shared functionality or resources. If two adjacent lines of code may produce different results if they run one after another, or if an instruction from another thread of execution is run between them, then a race condition vulnerability may be present.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Mitigating race condition vulnerabilities

Race condition vulnerabilities can have a significant impact on the functionality and security of an application. The simplest ways to eliminate race conditions are to remove the potential for parallel processing within an application or to ensure that different threads of execution do not share resources.

However, this is not an option in some cases and can negatively impact program performance in others. Two options for fixing the issue are the use of thread-safe programming and randomization.

Thread-safe programming

Race conditions visibilities exist when a function is not designed to be thread-safe. This essentially means that, if two threads of execution are running in parallel, then they may interfere with one another.

The potential for race condition vulnerabilities can be mitigated by designing all functions to be thread-safe. Ideally, this would involve designing a function so that multiple instances of the function can be executed in parallel without any interference with one another. Such a design enables the application to take full advantage of parallel processing.

If this is not an option, then a function or a particular set of instructions can be designed to be atomic (uses mutexes or similar tools). An atomic operation is one that is always run as a whole, i.e., no other threads of execution can interrupt its processing. By marking a block of code containing a race condition vulnerability as atomic, the potential vulnerability can be eliminated, since two threads cannot execute the instructions it contains at the same time.

However, marking code as atomic is not a perfect solution to race conditions. Two important considerations include:

• Multiple race condition vulnerabilities: If multiple different functions within an application use a shared resource in an insecure way, then marking each individually as atomic does not eliminate the vulnerability. Each atomic operation is independent, so an execution thread running one vulnerable function could still interfere with a thread running another that uses the same shared resource. Applications need to be architected so that shared resources that could create race conditions vulnerabilities are only accessible by one thread at a time.
• Loss of efficiency: Marking operations as atomic essentially makes that portion of the application single-threaded since only one thread of execution can run that code at a time and all others must wait their turn. As a result, the use of atomic operations creates a tradeoff between application efficiency and security against race conditions. The larger the atomic block, the less efficient the application.

Use of randomization

The filesystem is a resource that is shared among all applications on a computer. This means that it is not only possible to have race conditions between threads within an application, but also between multiple instances of the same application or multiple applications using the same file.

This means that applications using temporary files may be vulnerable to race conditions and exploitation. If two applications use the same temporary file, then they can interfere with one another. Alternatively, an attacker with knowledge of an application’s temporary file naming scheme can deliberately modify the file to impact the application’s operations.

When using temporary files and other named resources, the use of randomization is a good idea. While a temporary file with a random filename can still be exploitable if an attacker can identify the correct file, the use of randomization makes it more difficult to find and raises the bar for exploitation.

Learn Secure Coding

Build your secure coding skills in C/C++, iOS, Java, .NET, Node.js, PHP and other languages.

Learn More

Developing parallelized code securely

The use of parallel processing can be a major asset for an application. Parallelized code can run more quickly than single-threaded applications and is able to support multiple users in parallel.

However, parallelized code must be designed and implemented carefully. The use of shared resources or shared functions where different threads of execution can affect one another makes an application vulnerable to errors and potential exploitation.

Sources

1. What is a Race Condition?, Baeldung
2. Reentrant Function, GeeksforGeeks
3. Mutex lock for Linux Thread Synchronization, GeeksforGeeks