To learn about Race Conditions Vulnerability, let us start with an example – Imagine yourself in a bus, where all the seats are occupied and several people are standing. Now, the destination of one of the passengers seated has arrived. He gets down the bus leaving his seat vacant. You see that vacant seat and proceed towards it. But you are unaware of the fact that there is one more passenger in the bus who is approaching the same seat but, from the opposite side (who is also unaware of you). As you near that seat, you see that the other passenger reached before you and has already occupied the seat.
Consider this real life scenario. What just happened? Well, you just practically experienced a concept which in programming is termed as “the Race Condition Vulnerability”.
Race conditions has different names, such as Concurrency attacks or Threadjacking and so on…
Programmatically, Race Condition is a scenario where two or more threads try to access a shared resource, like a variable or a code and change it at the same time due to an undetermined execution of the thread in thread scheduling algorithm. Just like in the above scenario, both the passengers are unaware of each other, the second person reaches the seat first and so he gets it. It was a pretty random selection. Thus here:
Shared Resource: Seat
Thread1: You
Thread2: Passenger who got the seat
After execution, the value of shared resource (i.e the seat) changes from vacant to occupied. Pretty simple, no?
How does this simple condition become a critical flaw then?
Suppose if you are trying to book a ticket in a train where only 1 seat is empty. Simultaneously another passenger is also attempting to book a ticket for the same seat. What happens in this situation?
Technical Description
Technically, in this situation the following will occur:
Thread 1: logs in and looks for the seats and Thread 2: Logs in and looks for the seats too
Thread 1: if(availableseats>0)
{
seat.book(); //While the process of booking is being carried on
Thread 2: if(availableseats>0)
{
seat.book(); // Process
}
}
where
$availableseats=1;
function book()
{
availableseats=availableseats-1;
}
Race Conditions can be a security flaw too. In this, processes of different untrusted programs get in between the processes of secure programs causing them to misbehave. This causes the attacker to succeed in causing the problem. These scenarios are termed as “non-atomic”.
Let us take a quick real-world scenario here, consider the following PHP code for donating money from someone’s account to some other account:
What this code does is to simply get the balance details from the account, and check if there is enough money for donating. If so, proceed with the donation process and deduct the amount from the balance. This looks simple, but things get nasty when multiple requests execute at the same time. This is where the race conditions occur.
As you can see in the below screenshot I have ₹10,000
Now once we click on Donate ₹5000 for XYZ Organization it will deduct ₹5,ooo from our account as you can see in the below screenshot
To demonstrate this attack, I wrote a python script to make multiple requests to the URL:
When I execute this script it will make 2 simultaneous requests using os.fork(),resulting into deducting ₹10,000 from our account.
As you can see our balance has come ₹0. Now,what did just happen? Still Wondering?
Here, the 2 simultaneous requests reached the application at the same time, thus executing at the same time.
After the 1st request processes, the balance in the account should be 5000. But since we send 2 requests at the same time, both of them execute resulting in deduction of ₹10,000 from the account. This money transfers to my account.
Recommendations
In general terms, a lock system should be implemented. As in, when a particular thread is working on a resource, the resource should not be given access to any other thread unless it’s work is complete, especially if the thread is meant to overwrite new values. This is termed as “Sequencing”. As a contribution from our side, the program must be checked thoroughly to notice any part of the code that fails if any code is getting executed in between them.
While implementing locking, the other problems of locking, like deadlocks, also must be taken care of by ensuring that the threads do not have to wait forever for the corresponding processes to complete.
Race Conditions Exceptions are unchecked Exceptions which occur only in the runtime, and cannot be detected by the compiler, unlike the other kind of errors which the compiler detects as soon as it is typed. In order to prevent them, using Synchronised block around the shared resource is recommended to prevent multiple access at a time.
There are different tools available for detecting race conditions but they depend on upon the OS.
Mutex means Mutual Exclusion. It is a Computer Program that allows multiple threads to access the same resources, but not simultaneously.
Apart from this, it is also a good practice to minimise the number of shared resources if they are meant to change values.
Download Vulnerable code here
References
[1] Testing for Race Conditions(OWASP-AT-010)
[2] Practical Race Condition Vulnerabilities in Web Applications
[3] Thread Safety
