Resumen
El flujo de registro del primer usuario en Termix decide si esa cuenta se crea como administrador contando cuántos usuarios existen ya en la base de datos: si el conteo da cero, la nueva cuenta se crea como admin. El problema es que esa comprobación y la creación del usuario no ocurren de forma atómica — no están envueltas en una transacción — así que dos peticiones de registro enviadas casi al mismo tiempo pueden ambas "ver" que el conteo es cero antes de que ninguna haya insertado nada, y las dos terminan creándose como administradoras.
Mecánica de la condición de carrera
El patrón vulnerable es un clásico TOCTOU (Time-of-check to time-of-use):
- La petición A consulta
COUNT(*)de usuarios → obtiene 0. - Antes de que A termine de insertar su usuario, la petición B hace la misma consulta → también obtiene 0 (porque A todavía no insertó nada).
- Ambas peticiones proceden a crear su usuario con privilegios de administrador, porque ambas "vieron" una base de datos vacía.
En la práctica, esto requiere disparar dos (o más) peticiones de registro prácticamente en simultáneo, apenas segundos después de desplegar una instancia nueva de Termix y antes de que el primer usuario legítimo complete su registro.
Severidad
CVSS 3.1 base score 5.9 (Moderada) — vector de red, complejidad de ataque alta, sin privilegios requeridos, con impacto alto en confidencialidad. CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) y CWE-367 (TOCTOU Race Condition).
Ventana de explotación
Solo es explotable en el instante exacto entre que una instancia de Termix se despliega y el primer usuario legítimo completa su registro — un atacante necesitaría estar observando el despliegue en tiempo real y ganarle la carrera al administrador legítimo en una ventana de segundos. Fuera de ese momento puntual (con la instancia ya en uso, con usuarios existentes), la vulnerabilidad simplemente no aplica: el conteo ya no da cero.
Producto afectado
Termix (Termix-SSH), versiones ≤ 2.3.1. Corregido en 2.3.2.
Remediación
Corregido en Termix 2.3.2, envolviendo la comprobación de conteo y la inserción del primer usuario en una transacción atómica (o un constraint a nivel de base de datos), de forma que solo una de las peticiones concurrentes pueda ganar la carrera y crear la cuenta de administrador inicial.