Failure to follow proper concurrency management protocols can produce serious vulnerabilities. Concurrent access to shared resources without using appropriate concurrency management mechanisms produces hard-to-find vulnerabilities. Many "functions" that are necessary to use can introduce "time of check/time of use" vulnerabilities.
When multiple threads of control attempt to share the same resource but to not follow the appropriate concurrency protection protocol, then any of the following are possible:
Deadlock: one or more thread may become permanently blocked [Johansson 05].
Any of these can have security implications, sometimes manifest in apparent logic errors (decisions made based on corrupt data).
Competing "Systems" (Time of Check/Time of Use)
This is the most frequently encountered subclass of concurrency-related vulnerabilities. Many of the defects that produce these vulnerabilities are unavoidable due to limitations of the execution environment (i.e., the absence of proper concurrency control mechanisms). A common mitigation tactic is to minimize the time interval between check and use, but a more effective tactic is use a "check, use, check" pattern that can often detect concurrency violations, though not prevent them.
All of the following must be true:
Multiple "systems" must be operating concurrently.
At least two of those systems must use a shared resource (e.g., file, device, database table row).
At least one of those systems must use the shared resource in any of the following ways:
Without using any concurrency control mechanism. This includes the situation where no such mechanism exists, such a conventional UNIX filesystems, causing corruption or confusion.
Using the right concurrency control mechanism incorrectly. This includes situations like not using a consistent resource locking order across all systems (e.g., in databases), causing deadlocks.
Using the wrong concurrency control mechanism (even if it used correctly). This includes situations where a give resource may support multiple concurrency control mechanisms that are independent of one another (e.g., UNIX lockf() and flock()), causing corruption or confusion.
These defects are frequently referred to as time of check/time of use defects because APIs providing access to the resource neither provide any concurrency control operations nor perform any implicit concurrency control. In this case, a particular condition (e.g., availability of resource, resource attributes) is checked at one point in time and later program actions are based on the result of that check, but the condition could change at any time since no concurrency control mechanism guarantees the condition did not change.
Competing Threads within a "System" (Races)
The second largest class of concurrency-related vulnerabilities is generated by defects in the sharing of resources such as memory, devices, or files. The defect may be a design error associated with the concurrency control mechanisms or with an implementation error such as not correctly using those mechanisms. Caching errors can be considered a member of this class.
Strictly speaking, signal handling defects are not concurrency defects. Signal handlers are invoked preemptively in the main thread of the process. Therefore, signal handlers are not really concurrently executed. However, from the programmer's viewpoint, they mostly feel like concurrent execution, so we classify them here, at least for now.
All of the following must be true:
A "system" must have multiple concurrently operating threads of control.
Two or more of those threads must use a shared data object, device, or other resource.
At least one thread must use the shared resource without using the appropriate concurrency control mechanism correctly (or at all).
Impacts Being Mitigated
Maximally: Deadlock: one or more threads may become permanently blocked.
Maximally: Loss of information: saved information is overwritten by another thread.
Maximally: Loss of integrity of information: information written by multiple threads may be arbitrarily interlaced.
Maximally: Loss of liveness: imbalance in access to shared resources by competing threads can cause performance problems.
Security Policies to be Preserved
Threads must not deadlock.
Information must not be lost.
Information must not be corrupted.
Acceptable performance must be maintained.
How to Recognize this Defect
Concurrency defects are extremely difficult to recognize. There is no general purpose approach to finding them.
The appropriate concurrency control mechanism must be used in the conventional way (assuming there is one).
Where no concurrency control mechanism is available, seek to minimize the interval between the time of check and the time of use. Technically this does not correct the problem, but it can make the error much more difficult to exploit.
Bishop, Matt & Dilger, Mike. "Checking for Race Conditions in File Accesses." Computing Systems 9, 2 (1996): 131-152.
Gong, Li; Ellison, Gary; & Dageforde, Mary. Inside Java 2 Platform Security: Architecture, API Design, and Implementation (2nd Edition). Boston, MA: Addison-Wesley, 2003.
Johansson, Olof& Torvalds, Linus. Fix possible futex mmap_sem deadlock. http://linux.bkbits.net:8080/linux-2.6/cset@421cfc11zFsK9gxvSJ2t__FCmuUd3Q (2005). What is a futex anyway?
Manson, J. & Pugh, W. "Core semantics of multithreaded Java," 29-38. Proceedings of the 2001 Joint ACM-ISCOPE Conference on Java Grande. Palo Alto, California, USA, 2001. New York, NY: ACM Press, 2001. DOI= http://doi.acm.org/10.1145/376656.376806.
Manson, J.; Pugh, W.; & Adve, S. V. "The Java memory model," 378-391. Proceedings of the 32nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. Long Beach, California, USA, January 12-14, 2005. New York, NY: ACM Press, 2005. DOI= http://doi.acm.org/10.1145/1040305.1040336.
Pugh, W. "Fixing the Java memory model," 89-98. Proceedings of the ACM 1999 Conference on Java Grande. San Francisco, California, USA, June 12-14, 1999. New York, NY: ACM Press, 1999. DOI= http://doi.acm.org/10.1145/304065.304106.
Viega, John & McGraw, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston, MA: Addison-Wesley, 2002.
Rafail, Jason. Vulnerability Note VU#132110: Apache HTTP Server vulnerable to DoS race condition in the handling of short-lived connections. http://www.kb.cert.org/vuls/id/132110 (2004).
Copyright © Carnegie Mellon University 2005-2012.
This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at email@example.com.
The Build Security In (BSI) portal is sponsored by the U.S. Department of Homeland Security (DHS), National Cyber Security Division. The Software Engineering Institute (SEI) develops and operates BSI. DHS funding supports the publishing of all site content.
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.