El documento aborda las condiciones de carrera, que ocurren cuando múltiples subprocesos acceden a una variable compartida simultáneamente, lo que puede resultar en errores y vulnerabilidades de seguridad. Se describe cómo prevenir y detectar estas condiciones mediante semáforos, mutex y otras estrategias de sincronización, así como pruebas de rendimiento y análisis de código. También se ofrecen ejemplos de riesgos específicos en entornos .NET y herramientas para su análisis y corrección.

1. CONDICIONES DE
CARRERA
RACE CONDITION
Lic. Maribel Jiménez G.

2. Contenido
1. Introducción
2. Descripción del problema
3. Formas en que es susceptible de ser explotado.
4. Medidas preventivas, detección, correctivas.

3. Introducción
Una condición de carrera se produce cuando dos subprocesos
tienen acceso a una variable compartida al mismo tiempo.
Una condición de carrera es cuando dos diferentes contextos de
ejecución (hilos, procesos o tareas), pueden cambiar un recurso o
interferir con otro.
El primer subproceso lee la variable, y el segundo subproceso lee el
mismo valor de la variable. El primer y segundo subproceso realizan
sus operaciones en el valor y se ejecutan para ver qué subproceso
puede escribir el ultimo valor en la variable compartida.

4. 4
Usuario A
Usuario B
Deposito
$100
Retiro
$200
Cuent
a
Saldo
Final
$1100
Saldo
Inicial
$1000
Vista Inicial
1. Inicia pero se
interrumpe
2. Inicia y
concluye la
operación
3. Usuario
A concluye
operación
Saldo no registrado
$800
Descripción

5. 5
Descripción
Se asigna a cada subproceso un período predefinido de tiempo de
ejecución en un procesador.
Cuando caduca el tiempo asignado para el subproceso, se guarda el
contexto del subproceso hasta su próximo turno en el procesador y
el procesador comienza la ejecución del subproceso siguiente.
Es posible que el subproceso 1 complete su ejecución antes de que
su tiempo caduque en el procesador, a continuación, el subproceso
2 puede comenzar su ejecución, en esta caso no se produce la
condición de carrera.
Error aleatorio
En la ejecución del subproceso no se puede controlar el tiempo o el
orden de ejecución.
Los subprocesos se ejecutan de forma aleatoria haciendo que estos
errores sean mucho más difíciles de encontrar, depurar y

6. 6
Descripción
Propiedades necesarias para que pueda existir una condición de
carrera:
1. Concurrencia de propiedades.
Debe haber por lo menos dos flujos de control de ejecución al
mismo tiempo.
2. Objeto compartido.
Un objeto con la propiedad de ser compartido debe ser visitado
por flujos concurrentes.
3. Cambie la propiedad del Estado.
Al menos uno de los flujos de control deben alterar el estado del
objeto. Más de un subproceso o proceso debe escribir al mismo
recurso.

7. 7
Afectación
Cuando se presenta una condición de carrera, existe un intervalo de
tiempo durante el que un atacante puede obtener privilegios, leer y
escribir archivos protegidos, y vulnerar las políticas de seguridad del
sistema.

8. 8
Afectación

9. 9
Afectación

10. 10
Afectación

11. 11
Afectación

12. 12
Identificación
Se pueden realizar diferentes pruebas. El tiempo de ejecución es la métrica
más usada para la generación de informes.
Estrategias de pruebas
Las pruebas de una aplicación simultánea incluyen pruebas de:
 Corrección,
 Confiabilidad,
 Rendimiento
La corrección de la aplicación se comprueba mediante técnicas como:
 El análisis estático, analizan el código sin ejecutar el programa. se lleva a
cabo mediante la observación de los metadatos desde una aplicación
compilada o un código fuente anotado.

13. 13
Identificación
El rendimiento y la confiabilidad se prueban mediante el estudio de las
sobrecargas introducidas mediante el paralelismo y las pruebas de esfuerzo.
La escalabilidad se prueba mediante el análisis del rendimiento de la
aplicación en sistemas de diferentes tamaños.
Prefix y Prefast son dos de las herramientas de análisis estático más conocidas
para las aplicaciones nativas, mientras que FxCop es muy popular para trabajar
con código administrado.
 El análisis dinámico. Los errores se detectan al observar las superficies de
ejecución. Hay dos tipos de análisis dinámicos: con conexión y sin conexión.
Las herramientas que usan el análisis dinámico analizan un programa
mientras se ejecuta.
Algunas herramientas sólo pueden detectar una condición carrera si se produce
en la ejecución.

14. 14
Identificación
 La comprobación de modelos. El método para comprobar la corrección de
un sistema simultáneo de estado finito. Intenta simular las condiciones de
carrera y de bloqueo.
Este método ofrece una confianza superior en el diseño y en la arquitectura.
La comprobación de modelos puede demostrar que el diseño no tiene errores,
pero la implementación puede ser incorrecta.
Sólo resulta útil para secciones pequeñas y esenciales de un producto.

15. 15
Identificación
Herramientas de pruebas de simultaneidad
o CHESS Creada por Microsoft Research, es una nueva combinación de la
Comprobación de modelos y del Análisis dinámico.
o El Comprobador de subprocesos de Intel Se trata de una herramienta de
análisis dinámico para encontrar bloqueos, carreras de datos y usos
incorrectos de las API de sincronización nativas de Windows
o RacerX. Herramienta de análisis estático que distingue el flujo, se usa para
detectar carreras y bloqueos.
o Chord. Herramienta de análisis estático para Java que no distingue el flujo
pero sí el contexto. Al no distinguir el flujo puede ser más escalable que
otras herramientas estáticas, pero el precio es una pérdida de precisión.

16. 16
Identificación
o KISS. Desarrollada por Microsoft Research, es una herramienta de
Comprobación de modelos diseñada para los programas C simultáneos.
o Zing Esta herramienta es un comprobador de modelos puro pensado
para la comprobación de diseños de programas simultáneos

17. 17
Pruebas de rendimiento
Las pruebas de rendimiento son una parte integral y esencial del proceso
de prueba de simultaneidad.
En el caso de los escenarios de pruebas paralelas, se pueden usar las
siguientes variables como criterios de aceptación.
 Variación en los resultados de la prueba. Indica que se trata de una
aplicación inestable.
 Uso de CPU. Un uso bajo de la CPU podría ser señal de errores de
simultaneidad, como bloqueos y sobrecargas de sincronización.
 Uso total de memoria.
 El tiempo de ejecución total del subproceso.
Identificación

18. 18
Las soluciones para evitar la condición de carrera implican el uso de semáforos
y objetos de exclusión mutua (mutex) para proteger la sección crítica.
Métodos de sincronización para controlar las interacciones de subprocesos:
 Operaciones de bloqueo. Por ejemplo bloquear las variables compartidas,
por lo que sólo un subproceso tenga acceso a la variable compartida.
 Señalización. La manera más sencilla de esperar una señal de otro
subproceso es llamar un función, que lo pueda bloquear hasta que se
complete el otro subproceso.
 Interbloqueo. Dos subprocesos intentan bloquear un recurso que ya ha
bloqueado uno de estos subprocesos. Ninguno de los subprocesos puede
avanzar.
Hacer el código relevante (sección crítica) atómico con respecto a los
datos necesario, (atómico, el código se ejecuta como si fuera una sola
operación, sin interrupción), considerando que el código que ha de ser
atómico sea lo más pequeño posible.
Medidas preventivas

19. 19
Ejemplos de Riesgos de condición de carrera que se deben evitar en .NET:
 Condiciones de carrera en Método Dispose (libera todos los recursos que
posee, liberando memoria). Si el método Dispose no está sincronizado, es
posible que el código de limpieza de Dispose se ejecute más de una vez.
 Condiciones de carrera en constructores. En algunas aplicaciones, es
posible que otros subprocesos tengan acceso a miembros de clase antes de
que finalice la ejecución de sus constructores por lo que es necesario
sincronizar los subprocesos.
 Condiciones de carrera con objetos en caché. El código que almacena en
caché la información relacionada con la seguridad puede ser vulnerable a
condiciones de carrera si otras partes de la clase no están sincronizadas
correctamente.
 Condiciones de carrera en finalizadores. Si hay varios objetos que
comparten un recurso que se manipula en un finalizador de la clase, se deben
sincronizar los accesos a ese recurso en todos los objetos.
Medidas preventivas

20. 20
Referencias
Microsoft. (27 de Noviembre de 2013). Support. Obtenido de Description of race conditions and
deadlocks: http://support.microsoft.com/kb/317723
Microsoft (15 de enero de 2014) Seguridad y condiciones de carrera,
http://msdn.microsoft.com/es-es/library/1az4z7cb(v=vs.110).aspx?cs-save-lang=1&cs-
lang=vb#code-snippet-1
Microsoft (15 de enero de 2014) Información general sobre los primitivos de sincronización
http://msdn.microsoft.com/es-es/library/ms228964(v=vs.110).aspx
NIST, Vulnerabilidades y Exposiciones Comunes, (15 de enero de 2014)
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1284
CWE-362: Ejecución simultánea utilizando recursos compartidos con sincronización inadecuada
("condición de carrera"), (15 de enero de 2014)
http://cwe.mitre.org/data/definitions/362.html&usg=ALkJrhjfMpwH2n1lQJ2CBX_p-xDIrGying
Intenco, (15 de enero de 2014)
http://cert.inteco.es/vulnDetail/Actualidad/Actualidad_Vulnerabilidades/detalle_vulnerabilidad/
MSDN Magazine, Herramientas y técnicas para identificar los problemas de simultaneidad (15 de
enero de 2014), http://msdn.microsoft.com/es-es/magazine/cc546569.aspx