CWE-362

El producto contiene una secuencia de código concurrente que requiere acceso temporal y exclusivo a un recurso compartido, pero existe una ventana de tiempo en la que otra secuencia de código que se ejecuta de forma concurrente puede modificar dicho recurso compartido.

Una condición de carrera ocurre en entornos concurrentes y es, en efecto, una propiedad de una secuencia de código. Según el contexto, una secuencia de código puede tener la forma de una llamada a una función, un pequeño número de instrucciones, una serie de invocaciones de programa, etc. Una condición de carrera viola estas propiedades, que están estrechamente relacionadas: - Exclusividad: a la secuencia de código se le concede acceso exclusivo al recurso compartido; es decir, ninguna otra secuencia de código puede modificar las propiedades del recurso compartido antes de que la secuencia original haya completado su ejecución. - Atomicidad: la secuencia de código es atómica en su comportamiento; es decir, ningún otro hilo o proceso puede ejecutar de forma concurrente la misma secuencia de instrucciones (o un subconjunto) sobre el mismo recurso. Existe una condición de carrera cuando una "secuencia de código interferente" todavía puede acceder al recurso compartido, violando la exclusividad. La secuencia de código interferente puede ser "confiable" o "no confiable". Una secuencia de código interferente confiable ocurre dentro del producto; no puede ser modificada por el atacante y solo puede invocarse de forma indirecta. Una secuencia de código interferente no confiable puede ser escrita directamente por el atacante y, por lo general, es externa al producto vulnerable.

Consecuencias comunes

• Disponibilidad → DoS: consumo de recursos (CPU), DoS: consumo de recursos (memoria), DoS: consumo de recursos (otros)
• Disponibilidad → DoS: caída, salida o reinicio, DoS: inestabilidad
• Confidencialidad, Integridad → Leer archivos o directorios, Leer datos de la aplicación
• Control de acceso → Ejecutar código o comandos no autorizados, Obtener privilegios o asumir identidad, Eludir el mecanismo de protección

Mitigaciones

• Arquitectura y diseño: En los lenguajes que lo admitan, use primitivas de sincronización. Envuelva con ellas únicamente el código crítico para minimizar el impacto en el rendimiento.
• Arquitectura y diseño: Use capacidades seguras para hilos, como la abstracción de acceso a datos de Spring.
• Arquitectura y diseño: Minimice el uso de recursos compartidos para eliminar la mayor complejidad posible del flujo de control y reducir la probabilidad de que se produzcan condiciones inesperadas. Además, esto minimizará la cantidad de sincronización necesaria e incluso puede ayudar a reducir la probabilidad de una denegación de servicio en la que un atacante pueda desencadenar repetidamente una
• Implementación: Al usar multithreading y operar sobre variables compartidas, use únicamente funciones seguras para hilos.
• Implementación: Use operaciones atómicas sobre las variables compartidas. Desconfíe de construcciones de apariencia inocente como "x++". Esto puede parecer atómico en la capa del código, pero en realidad no lo es en la capa de instrucciones, ya que implica una lectura, seguida de un cálculo, seguido de una escritura.
• Implementación: Use un mutex si está disponible, pero asegúrese de evitar debilidades relacionadas, como la CWE-412.