Security and Race Conditions
Another area of concern is the potential for security holes exploited by race conditions. There are several ways in which this might happen. The subtopics that follow outline some of the major pitfalls that the developer must avoid.
If a class's Dispose method (for more information, see Garbage Collection) is not synchronized, it is possible that cleanup code inside Dispose can be run more than once, as shown in the following example.
Sub Dispose() If Not (myObj Is Nothing) Then Cleanup(myObj) myObj = Nothing End If End Sub
Because this Dispose implementation is not synchronized, it is possible for Cleanup to be called by first one thread and then a second thread before _myObj is set to null. Whether this is a security concern depends on what happens when the Cleanup code runs. A major issue with unsynchronized Dispose implementations involves the use of resource handles such as files. Improper disposal can cause the wrong handle to be used, which often leads to security vulnerabilities.
Code that caches security information or uses the code access security Assert operation might also be vulnerable to race conditions if other parts of the class are not appropriately synchronized, as shown in the following example.
Sub SomeSecureFunction() If SomeDemandPasses() Then fCallersOk = True DoOtherWork() fCallersOk = False() End If End Sub Sub DoOtherWork() If fCallersOK Then DoSomethingTrusted() Else DemandSomething() DoSomethingTrusted() End If End Sub
If there are other paths to DoOtherWork that can be called from another thread with the same object, an untrusted caller can slip past a demand.
If your code caches security information, make sure that you review it for this vulnerability.