Node.js allows developers to assign callbacks to IO-blocked events. This allows better performance as the callbacks run asynchronously such that the main application isn't blocked by IO. However, this in turn may lead to race conditions when something outside the callback relies upon code within the callback to be run first.

Example 1: The following code checks a user against a database for authentication.

 
...
var authenticated = true; 
...
database_connect.query('SELECT * FROM users WHERE name == ? AND password = ? LIMIT 1', userNameFromUser, passwordFromUser, function(err, results){
  if (!err && results.length > 0){
    authenticated = true;
  }else{
    authenticated = false;
  }
});

if (authenticated){
  //do something privileged stuff
  authenticatedActions();
}else{
  sendUnathenticatedMessage();
}

In this example we're supposed to be calling to a backend database to confirm a user's credentials for login, and if confirmed we set a variable to true, otherwise false. Unfortunately, since the callback is blocked by IO, it will run asynchronously and may be run after the check to if (authenticated), and since the default was true, it will go into the if-statement whether the user is actually authenticated or not.

The app installs an application from shared storage where any application with external storage read/write permissions can write to. Due to a race condition, the malicious app monitoring the folder can swap a downloaded APK file for an alternate APK file, which the installation process will use in place of the legitimate update.

Example 1: The following code installs an applications from the shared storage:

    Intent intent = new Intent(Intent.ACTION_VIEW);
    intent.setDataAndType(Uri.fromFile(new File(Environment.getExternalStorageDirectory() + "/download/" + "app.apk")), "application/vnd.android.package-archive");
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
    startActivity(intent);

File access race conditions, known as time-of-check, time-of-use (TOCTOU) race conditions, occur when:

1. The program checks a property of a file, referencing the file by name.

2. The program later performs a file system operation using the same filename and assumes that the previously-checked property has not changed.
Example 1: The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should not be available to the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.

  if (!access(file,W_OK)) {
    f = fopen(file,"w+");
    operate(f);
    ...
  }
  else {
    fprintf(stderr,"Unable to open file %s.\n",file);
  }

The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges.

This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.

The window of vulnerability for such an attack is the period of time between when the property is tested and when the file is used. Even if the use immediately follows the check, modern operating systems offer no guarantee about the amount of code that is executed before the process yields the CPU. Attackers have a variety of techniques to expand the length of the window of opportunity in order to make exploits easier. However, even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

Example 2: The following code creates a file and then changes the owner of the file.

    fd = creat(FILE, 0644);  /* Create file */
    if (fd == -1)
        return;
    if (chown(FILE, UID, -1) < 0) {  /* Change file owner */
      ...
    }

The code assumes that the file operated upon by the call to chown() is the same as the file created by the call to creat(), but that is not necessarily the case. Since chown() operates on a file name and not on a file handle, an attacker may be able to replace the file with a link to file the attacker does not own. The call to chown() would then give the attacker ownership of the linked file.

The methods parse() and format() in java.text.Format contains a race condition that can cause one user to see another user's data.

Example 1: The following code shows how this design flaw can manifest itself.

public class Common {

    private static SimpleDateFormat dateFormat;
    ...

    public String format(Date date) {
        return dateFormat.format(date);
    }
    ...

    final OtherClass dateFormatAccess=new OtherClass();
    ...

    public void function_running_in_thread1(){
        System.out.println("Time in thread 1 should be 12/31/69 4:00 PM, found: "+ dateFormatAccess.format(new Date(0)));
    }

    public void function_running_in_thread2(){
        System.out.println("Time in thread 2 should be around 12/29/09 6:26 AM, found: "+ dateFormatAccess.format(new Date(System.currentTimeMillis())));
    }
}

While this code will behave correctly in a single-user environment, if two threads run it at the same time they could produce the following output:

Time in thread 1 should be 12/31/69 4:00 PM, found: 12/31/69 4:00 PM
Time in thread 2 should be around 12/29/09 6:26 AM, found: 12/31/69 4:00 PM

In this case, the date from the first thread is shown in the output from the second thread due a race condition in the implementation of format().

The RoamingFolder and RoamingSettings properties get a container in the roaming app data store, which can then be used to share data between two more devices. By writing and reading objects stored in the roaming app data store, the developer increases the risk of compromise. This includes the confidentiality, integrity, and availability of the data, applications, and systems which share those objects through the roaming app data store.

Developers should refrain from using this functionality without first implementing the necessary technical controls.

Signal handling race conditions can occur whenever a function installed as a signal handler is non-reentrant, which means it maintains some internal state or calls another function that does so. Such race conditions are even more likely when the same function is installed to handle multiple signals.

Signal handling race conditions are more likely to occur when:

1. The program installs a single signal handler for more than one signal.

2. Two different signals for which the handler is installed arrive in short succession, causing a race condition in the signal handler.

Example: The following code installs the same simple, non-reentrant signal handler for two different signals. If an attacker causes signals to be sent at the right moments, the signal handler will experience a double free vulnerability. Calling free() twice on the same value can lead to a buffer overflow. When a program calls free() twice with the same argument, the program's memory management data structures become corrupted. This corruption can cause the program to crash or, in some circumstances, cause two later calls to malloc() to return the same pointer. If malloc() returns the same value twice and the program later gives the attacker control over the data that is written into this doubly-allocated memory, the program becomes vulnerable to a buffer overflow attack.

void sh(int dummy) {
  ...
  free(global2);
  free(global1);
  ...
}

int main(int argc,char* argv[]) {
  ...
  signal(SIGHUP,sh);
  signal(SIGTERM,sh);
  ...
}

Many Servlet developers do not understand that a Servlet is a singleton. There is only one instance of the Servlet, and that single instance is used and re-used to handle multiple requests that are processed simultaneously by different threads.

A common result of this misunderstanding is that developers use Servlet member fields in such a way that one user may inadvertently see another user's data. In other words, storing user data in Servlet member fields introduces a data access race condition.

Example 1: The following Servlet stores the value of a request parameter in a member field and then later echoes the parameter value to the response output stream.

public class GuestBook extends HttpServlet {

   String name;

   protected void doPost (HttpServletRequest req, HttpServletResponse res) {
     name = req.getParameter("name");
     ...
     out.println(name + ", thanks for visiting!");
   }
}

While this code will work perfectly in a single-user environment, if two users access the Servlet at approximately the same time, it is possible for the two request handler threads to interleave in the following way:

Thread 1: assign "Dick" to name
Thread 2: assign "Jane" to name
Thread 1: print "Jane, thanks for visiting!"
Thread 2: print "Jane, thanks for visiting!"

Thereby showing the first user the second user's name.