If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
C
C++
Java
.NET
Common Consequences
Scope
Effect
Integrity
Other
Technical Impact: Alter execution
logic; Unexpected state
The main problem is that -- if a lock is overcome -- data could be
altered in a bad state.
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
(Bad Code)
Example Languages: C and C++
int foo = 0;
int storenum(int num) {
static int counter = 0;
counter++;
if (num > foo) foo = num;
return foo;
}
(Bad Code)
Example
Language: Java
public classRace {
static int foo = 0;
public static void main() {
new Threader().start();
foo = 1;
}
public static class Threader extends Thread {
public void run() {
System.out.println(foo);
}
}
}
Potential Mitigations
Phase: Architecture and Design
Use locking functionality. This is the recommended solution. Implement
some form of locking mechanism around code which alters or reads
persistent data in a multithreaded environment.
Phase: Architecture and Design
Create resource-locking sanity checks. If no inherent locking
mechanisms exist, use flags and signals to enforce your own blocking
scheme when resources are being used by other threads of
execution.
Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
References
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 13: Race Conditions." Page 205. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 13, "Race Conditions", Page 759.. 1st Edition. Addison Wesley. 2006.
Description
