Reviewing Code for Race Conditions - Revision history

Thomas Herlea: Added navigation to facilitate sequential reading online

2010-09-09T16:40:37Z

Added navigation to facilitate sequential reading online

Jason Li: This page is linked by an external page (Application Security and Development STIG: disa.mil)

2009-04-28T20:33:09Z

This page is linked by an external page (Application Security and Development STIG: disa.mil)

KirstenS: /* Related Articles */

2009-02-11T01:53:22Z

‎Related Articles

KirstenS: /* Vulnerable Patterns for Race Conditions */

2009-02-11T01:51:54Z

‎Vulnerable Patterns for Race Conditions

KirstenS: /* Introduction */

2009-02-11T01:51:04Z

‎Introduction

KirstenS: /* Classic ASP */

2009-01-28T15:40:53Z

‎Classic ASP

KirstenS: /* How They Work */

2009-01-28T15:40:02Z

‎How They Work

KirstenS: /* Vulnerable Patterns for Race Conditions */

2009-01-13T18:08:54Z

‎Vulnerable Patterns for Race Conditions

KirstenS: /* How to locate the potentially vulnerable code */

2009-01-13T18:08:11Z

‎How to locate the potentially vulnerable code

KirstenS: /* How they work: */

2009-01-13T18:06:51Z

‎How they work:

@@ Line 1: / Line 1: @@
-[[OWASP Code Review Guide Table of Contents]]__TOC__
+{{LinkBar
 == Introduction ==
@@ Line 57: / Line 62: @@
 http://msdn2.microsoft.com/en-us/library/f857xew0(vs.71).aspx
 [[Category:OWASP Code Review Project]]

@@ Line 60: / Line 60: @@
 [[Category:OWASP Code Review Project]]
 [[Category:Data Integrity|TOCTTOU]]
 [[Category:FIXME|the second category doesn't exist; which should be there?]]

← Older revision		Revision as of 01:53, 11 February 2009
Line 60:		Line 60:
	[[Category:OWASP Code Review Project]]		[[Category:OWASP Code Review Project]]
	[[Category:Data Integrity\|TOCTTOU]]		[[Category:Data Integrity\|TOCTTOU]]
		+
		+	[[Category:FIXME\|the second category doesn't exist; which should be there?]]

@@ Line 50: / Line 50: @@
 Instances of classes do not need to be thread safe as one is made per operation/request. Static states must be thread safe.
 #References to static variables, these must be thread locked.
 #Releasing a lock in places other then finally{} may cause issues

@@ Line 2: / Line 2: @@
 == Introduction ==
-Race Conditions occur when a piece of code does not work as it is supposed to (like many security issues). They are the result of an unexpected ordering of events which can result in the finite state machine of the code to transition to a undefined state and also give rise to contention of more than one thread of execution over the same resource. Multiple threads of execution acting or manipulating the same area in memory or persisted data which gives rise to integrity issues.
+Race Conditions occur when a piece of code does not work as it is supposed to (like many security issues). They are the result of an unexpected ordering of events, which can result in the finite state machine of the code to transition to a undefined state, and also give rise to contention of more than one thread of execution over the same resource. Multiple threads of execution acting or manipulating the same area in memory or persisted data which gives rise to integrity issues.
 ==How They Work==

@@ Line 44: / Line 44: @@
 ===Classic ASP===
-Multithreading is not directly supported feature of classic ASP, so this kind of race condition could be present only when using COM objects.
+Multithreading is not a directly supported feature of classic ASP, so this kind of race condition could be present only when using COM objects.
 ==Vulnerable Patterns for Race Conditions==

@@ Line 11: / Line 11: @@
   X = X + 10
-So with no controls surrounding this code in a multithreaded environment, we get the following problem:
+With no controls surrounding this code in a multithreaded environment, we get the following problem:
   T1 places X into a register in thread 1

@@ Line 22: / Line 22: @@
 The value should actually be 25, as each thread added 10 to the initial value of 5. But the actual value is 15 due to T2 not letting T1 save into X before it takes a value of X for its addition.
-==How to locate the potentially vulnerable code==
+==How to Locate the Potentially Vulnerable Code==
 ===.NET===
 Look for code which used multithreaded environments:
   Thread
   System.Threading
@@ Line 45: / Line 44: @@
 ===Classic ASP===
-Notice multithreading is not directly supported feature of classic ASP so this kind of race conditions could be present only when using COM objects.
+Multithreading is not directly supported feature of classic ASP, so this kind of race condition could be present only when using COM objects.
 ==Vulnerable Patterns for Race Conditions==

@@ Line 4: / Line 4: @@
 Race Conditions occur when a piece of code does not work as it is supposed to (like many security issues). They are the result of an unexpected ordering of events which can result in the finite state machine of the code to transition to a undefined state and also give rise to contention of more than one thread of execution over the same resource. Multiple threads of execution acting or manipulating the same area in memory or persisted data which gives rise to integrity issues.
-==How they work:==
+==How They Work==
-With competing tasks manipulating the same resource we can easily get a race condition as the resource is not in step-lock or utilises a token based multi-use system such as semaphores.
+With competing tasks manipulating the same resource, we can easily get a race condition as the resource is not in step-lock or utilises a token based multi-use system such as semaphores.
-Say we have two processes (Thread 1, T1) and (Thread 2, T2).
+Say we have two processes (Thread 1, T1) and (Thread 2, T2). The code in question adds 10 to an integer X. The initial value of X is 5.
   X = X + 10
-So with no controls surrounding this code in a multithreaded environment we get the following problem:
+So with no controls surrounding this code in a multithreaded environment, we get the following problem:
   T1 places X into a register in thread 1
@@ Line 21: / Line 20: @@
   T1 saves the register value (15) into X.
-The value should actually be 25 as each thread added 10 to the initial value of 5. But the actual value is 15 due to T2 not letting T1 save into X before it takes a value of X for its addition.
+The value should actually be 25, as each thread added 10 to the initial value of 5. But the actual value is 15 due to T2 not letting T1 save into X before it takes a value of X for its addition.
 ==How to locate the potentially vulnerable code==