Operating Systems - Race Condition Vulnerability

---

---

Race Condition

In an operating system, a race condition is an undesirable situation that occurs when multiple processes or threads access and manipulate a shared resource concurrently, leading to inconsistent outputs. The outcome of the execution is dependent upon the order of execution of the individual statements of the processes which are executing in a preemptive environment. The shared resource may be a shared variable, a table or a file. The processes are racing against each other to gain access to the shared resource and so the scenario is called race condition.

Example of Race Condition

Let us consider a scenario of two processes, P1 and P2 which are trying to change the value of a shared variable stored at memory location C, which is initially 10. P1 wants to increment the value of C, while P2 wants to decrement the value of C. The activity of increment or decrement is not a single statement but corresponds to multiple statements as stated below.

The Statements of P1 are −

R1 ← M(C) [loads contents of memory location C to register R1]

R1 ← R1 + 1 [increments contents of register R1]

M(C) ← R1 [stores contents R1 to memory location C]

The Statements of P2 are −

R2 ← M(C) [loads contents of memory location C to register R2]

R2 ← R2 - 1 [decrements contents of register R1]

M(C) ← R2 [stores contents R2 to memory location C]

In an ideal situation, P1 executes in its entirety and then P2 executes or the vice versa. So, after both the processes execute the value of C remains the same, i.e. 10. However, since P1 and P2 are racing against each other and each process may preempt the other, the statements are intertwined. Let us look through two different scenarios resulting in different outputs.

Scenario 1 −

In the above scenario, we find that the increment done by process P1 is entirely lost and the value of C is 9, which is incorrect.

Scenario 2 −

In the above scenario, we find that the decrement done by process P2 is lost and the value of C is 11, which is incorrect too.

From the above two scenarios, we observe that if the portions of code that changes a shared resource are not executed in an atomic manner, the results may be incorrect or lost.

Race Condition Vulnerability

Race condition vulnerability is a software bug that allows malicious entities to exploit the execution of concurrent processes in race condition so that they yield inconsistent outputs. It is a vital security vulnerability recognised as CWE-362 (Common Weakness Enumeration, section 362).

It is caused when an erroneous code is inserted in between Time-ofcheck (TOC) and Time-of-use (TOU) window of a process or thread either maliciously or deliberately.

Some examples of race condition vulnerabilities are as follows −

• A Hacker can interfere with the security system in the process of checking the login credentials before giving the access. The attack is performed by inserting a malicious code between the TOC and TOU, then authenticating the unauthorized users to access the system.
• In case of temporary files, the attacker will create or change the file with some common name suggestion to store the sensitive data. With this, the attacker can change the behavior of the system leading to vulnerability.
• When the users want to access any file or data, they are prompted like the file needs permission to access. Using this, the data and file may lead to corruption or loss.
• The Attacker may open the database and change the data according to their needs like in case of updating the employees salary information in the database with respect to the performance, they can increase the salary for the low-performance employees and vice versa.

Consequences of Race Condition

Race condition vulnerability has some serious consequences that ruptures the security system and its functionalities like,

• Race conditions may lead to data loss and data corruption of shared files and shared tables.
• When kernel processes are subject to race condition vulnerability, they may execute for infinite time leading to system crash.
• During login sessions, unauthorized people may gain access to the system.
• When more than one process is racing to use the shared resources, it may happen that some processes are holding some resources while waiting for other resources. This leads to a deadlock situation.

Protection from Race Condition Vulnerabilities

Race condition vulnerabilities have serious consequences that degrades the overall performance of the system and compromises system security. So, it is mandatory to adopt proper protection measures so that these situations are avoided as much as practicable.

Some commonly used measures are listed as follows −

• Atomic Operations − If the sequence of instructions of any operation are executed as a single unit, it is called an atomic operation. Atomic operations do not allow interruptions and hence ensure that multiple processes cannot access a shared resource simultaneously.
• Synchronization − In order that only one process or thread can access a shared resource at any time, synchronization mechanisms are used like locks, semaphores, mutexes or monitors.
• Access Limits − The window of vulnerability spanning TOCTOU can be minimized or optimized so as to limit the duration of accessing the resources.
• Detection Measures − Automated analysis and testing tools help to review code periodically to detect race conditions.
• Maintaining Logs − Maintaining proper system logs assists in tracking access to shared resource and out-of-order operations, indicating a race condition.
• Web Application Firewalls − Web application firewalls prevent web attacks which in turn prevent the vulnerabilities in the TOCTOU.