Race Conditions

(OBJ 2.3)

Race Conditions

• Software vulnerabilities related to the order and timing of events in concurrent processes/events
• Exploiting race conditions allows attackers to disrupt intended program behavior and gain unauthorized access
  • Run the attacker's processes before running yours

Understanding Race Conditions

• Race conditions occur when multiple threads or processes access and manipulate shared resources simultaneously
• Dereferencing
  • Software vulnerability that occurs when the code attempts to remove the relationship between a pointer and the thing that the pointer was pointing to in the memory which allows changes to be made
  • Allows changes to the memory location
• Vulnerabilities stem from unexpected conflicts and synchronization issues

Exploiting Race Conditions

• Attackers exploit race conditions by timing their actions to coincide with vulnerable code execution
• Exploitation may lead to unauthorized access, data manipulation, or system crashes

Dirty COW Exploit

• A real-world example of race condition exploitation
• Targeted Linux and Android systems, leveraging race conditions in the Copy On Write function
• Popular 2016 exploit, showcasing a race condition exploitation
• COW = Copy-on-write
• Linux OSs being exploited to allow local privilege escalation to occur by exploiting a race condition vulnerability based on the implementation of the programming for the copy and write function used inside of the Kernel's memory management system.
• They used a race condition to turn the read-only condition of a file into a write
• It was difficult to detect, didn't even leave anything inside of system logs

Types of Race Conditions

• Time-of-Check (TOC)
  • Attackers manipulate a resource's state after it is checked but before it is used
  • Makes a decision based on that check
  • For example, overdrawing a bank account due to a time delay between checking and transferring funds
• Time-of-Use (TOU)
  • Attackers alter a resource's state after it is checked but before it is used
  • Focuses on the time when the resource is utilized, rather than the time of the initial check
  • TOU is more general and not necesarily involves a prior "check"
• Time-of-Evaluation (TOE)
  • Attackers manipulate data or resources during the system's decision-making or evaluation process
  • Can lead to incorrect results or unexpected behavior
  • Example:
    • Manipulate inputs being used inside of a calculation to cause incorrect results to be sued instead

Mitigating Race Conditions

• Use locks and mutexes to synchronize access to shared resources
  • Mutex
    • Mutually exclusive flag that acts as a gatekeeper to a section of code so that only one thread can be processed at a time
    • Mutexes ensure only one thread or process can access a specific section of code at a time
• Properly design and test locks to prevent deadlocks
• Deadlock
  • Occurs when a lock remains in place because the process it’s waiting for is terminated, crashes, or doesn’t finish properly, despite the processing being complete
  • Causes the lock to never be removed by the resource even though the processing was competed.
  • When this occurs, the system/code can lose access to the resource until the lock is overridden or manually removed
  • To prevent deadlocking:
    • Properly design any locks or mutexes that you're using inside of your code to prevent a race condition