Una aplicación J2EE puede utilizar varios JVM a fin de mejorar la confiabilidad y el rendimiento de la aplicación. A fin de hacer que varios JVM aparezcan como una única aplicación para el usuario final, el contenedor J2EE puede replicar un objeto HttpSession entre varios JVM. De este modo, si un JVM deja de estar disponible otro puede intervenir y ocupar su lugar sin deteriorar el flujo de la aplicación.

Para que la replicación de sesión funcione, los valores que almacena a aplicación como atributos en la sesión deben implementar la interfaz Serializable.

Ejemplo 1: la clase siguiente se agrega a la sesión, pero como no es serializable, la sesión ya no puede replicarse.

public class DataGlob {
   String globName;
   String globValue;

   public void addToSession(HttpSession session) {
     session.setAttribute("glob", this);
   }
}

La administración de subprocesos en una aplicación web está prohibida por el estándar J2EE en algunas circunstancias y siempre es susceptible a errores. La administración de subprocesos es una tarea complicada y es muy probable que esta interfiera de forma impredecible en el comportamiento del contenedor de aplicaciones. Incluso aunque no interfiera en el contenedor, la administración de subprocesos suele provocar errores difíciles de detectar y diagnosticar, como interbloqueos, condiciones de carrera y otros errores de sincronización.

Los valores asociados con block.timestamp o block.number suelen ser usados por los desarrolladores para activar eventos dependientes del tiempo; sin embargo, estos valores a menudo dan una sensación de tiempo que no es seguro usar.

Debido a la naturaleza descentralizada de blockchain, los nodos pueden sincronizar el tiempo solo hasta cierto punto. En el mejor de los casos, usar block.timestamp no es fiable y, en el peor, los mineros maliciosos pueden alterar la marca de tiempo de sus bloques si ven una ventaja en hacerlo.

En cuanto a block.number, aunque es posible predecir el tiempo entre bloques (aproximadamente 14 segundos), los tiempos de los bloques no son constantes y pueden variar dependiendo de la actividad de la red. Esto hace que block.number no sea fiable para los cálculos relacionados con el tiempo.

Ejemplo 1: El siguiente código utiliza block.number para desbloquear fondos después de un cierto período de tiempo.

function withdraw() public {
    require(users[msg.sender].amount > 0, 'no amount locked');
    require(block.number >= users[msg.sender].unlockBlock, 'lock period not over');
    uint amount = users[msg.sender].amount;
    users[msg.sender].amount = 0;
    (bool success, ) = msg.sender.call.value(amount)("");
    require(success, 'transfer failed');
}

Node.js permite a los desarrolladores asignar devoluciones de llamada a eventos bloqueados de E/S. Esto permite una mejora del rendimiento, ya que las devoluciones de llamada se ejecutan de forma asíncrona de manera que la E/S no bloquee la aplicación. Sin embargo, esto a su vez puede dar lugar a condiciones de carrera cuando algo fuera de la devolución de llamada dependa de que se ejecute primero código que se encuentra dentro de la devolución de llamada.

Ejemplo 1: el siguiente código contrasta la información de un usuario con una base de datos para su autenticación.

 
...
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();
}

En este ejemplo, supondremos que estamos llamando a una base de datos de back-end para confirmar las credenciales de un usuario para iniciar sesión y, si se confirman, definiremos una variable como true; en caso contrario, como false. Desafortunadamente, como hay E/S que bloquea la devolución de llamada, esta se ejecutará de forma asíncrona y puede que se ejecute después de la comprobación if (authenticated), y como el valor predeterminado era true, irá en la instrucción if tanto si el usuario se ha autenticado realmente como si no.

La aplicación instala un formulario de aplicación desde el almacenamiento compartido en el que puede escribir cualquier aplicación con permisos de lectura/escritura de almacenamiento externo. Debido a una condición de carrera, la aplicación maliciosa que supervise la carpeta podrá cambiar un archivo APK descargado por otro archivo APK, el cual se usará en el proceso de instalación en lugar del archivo legítimo.

Ejemplo 1: El código siguiente instala aplicaciones desde el almacenamiento compartido:

    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);

Las condiciones de carrera de acceso a archivos, conocidas como condiciones de carrera de momento de comprobación y momento de uso (TOCTOU, por sus siglas en inglés) se producen cuando:

1. El programa comprueba una propiedad de un archivo, haciendo referencia a este por el nombre.

2. A continuación el programa realiza una operación de sistema del archivo utilizando el mismo nombre de archivo y asume que la propiedad que ya se comprobó anteriormente no ha cambiado.
Ejemplo 1: El siguiente código procede de un programa instalado setuid root. El programa realiza ciertas operaciones de archivo en nombre de usuarios no privilegiados, y usa comprobaciones de acceso para asegurar que este no usa sus privilegios origen para realizar operaciones que no deberían estar disponibles para el usuario actual. El programa utiliza la llamada al sistema access() para comprobar si la persona que está ejecutando el programa tiene permiso para acceder al archivo especificado antes de que abra el archivo y realiza las operaciones necesarias.

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

La llamada a access() presenta el comportamiento previsto y devuelve 0 si el usuario que ejecuta el programa dispone de los permisos necesarios para escribir en el archivo y, de no ser así, devuelve -1. Sin embargo, debido a que tanto access() como fopen() realizan operaciones en los nombres de archivo en lugar de en los identificadores de archivo, no hay ninguna garantía de que la variable file aún haga referencia al mismo archivo en el disco al transferirlo a fopen() que cuando se transfirió a access(). Si un usuario malintencionado sustituye file tras la llamada a access() por un vínculo simbólico a un archivo diferente, el programa utilizará sus privilegios raíz para realizar operaciones en el archivo, aunque se trate de un archivo que, de lo contrario, el usuario no podría modificar. Al engañar al programa para que realice una operación que, de lo contrario, no sería permisible, el usuario malintencionado ha obtenido privilegios elevados.

Este tipo de vulnerabilidad no se limita a programas con privilegios root. Si la aplicación es capaz de realizar cualquier operación que el usuario malintencionado no tendría permiso para realizar, se trata de un posible objetivo.

La ventana de vulnerabilidad para un ataque de esta naturaleza se da en el período de tiempo entre cuando una propiedad de archivo se comprueba y cuando el archivo se usa. Incluso si el uso se produce inmediatamente después de la comprobación, los sistemas de operación modernos no garantizan la cantidad de código que se ejecuta antes de que el proceso abandona la CPU. Los atacantes disponen de una amplia variedad de técnicas para expandir la longitud de la ventana de oportunidad para que sea más fácil de explotar. Sin embargo, incluso con una ventana pequeña, un intento de ataque puede repetirse una y otra vez hasta que tiene éxito.

Ejemplo 2: el siguiente código crea un archivo y, a continuación, cambia el propietario del mismo.

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

Este código presupone que el archivo utilizado por la llamada a chown() es el mismo que el archivo creado por la llamada a creat(), pero esto no siempre es así. Como chown() funciona en un nombre de archivo y no en un identificador de archivo, un atacante podría ser capaz de reemplazar el archivo con un vínculo a un archivo que no posee el atacante. La llamada a chown() proporcionaría así al atacante la propiedad del archivo vinculado.

Los métodos parse() y format() de java.text.Format contienen una condición de carrera que puede ocasionar que un usuario vea los datos de otro usuario.

Ejemplo 1: El código siguiente muestra cómo se puede manifestar el error de diseño.

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())));
    }
}

Mientras que este código se comporta correctamente en un entorno de usuario único, si dos subprocesos se ejecutan a la vez podrían producir la salida siguiente:

La hora en el subproceso 1 debería ser 31/12/69 4:00 PM, encontrado: 31/12/69 4:00 PM
La hora en el subproceso 2 debería ser 12/29/09 6:26 AM, encontrado: 31/12/69 4:00 PM

En este caso, la fecha desde el primer subproceso se muestra en la salida desde el segundo subproceso debido a una condición de carrera en la implementación de format().