Un bug de 37 años daba root en el sistema operativo más seguro

Un investigador de seguridad acaba de conseguir una shell de root en OpenBSD, el sistema operativo que lleva décadas vendiéndose como el más duro del planeta. Y lo hizo con un contador que nació en el BSD original, de hace 37 años. 🔐

No fue un error de configuración, no fue phishing, no fue una contraseña robada. Fue aritmética: un número de 16 bits que se desbordó.

El sistema "indestructible" tenía un contador viejísimo

El equipo de Calif (Andrew Griffiths) publicó hoy "Big Fish", la investigación completa. El culpable es shm_nattch, un contador de adjuntos de memoria compartida definido como un short con signo de 16 bits, heredado directamente de las fuentes originales de BSD de hace 37 años.

Ese número máximo es 32.767. Si repites el proceso de forkear y adjuntar memoria compartida, la cuenta sube, sube... y un día se da la vuelta a negativo.

El desbordamiento abre la puerta a un use-after-free por condición de carrera, que combinado con una escritura fuera de límites del kernel da escalada local a root. Y ojo: con KARL, SMAP y SMEP activos, sin necesitar ninguna fuga de información previa.

Así se ve el exploit, en 5 movimientos

La receta es tan elegante como absurda: 🍳

1. Mapeas 127 segmentos de memoria compartida SysV, los desmapeas y haces fork de 259 procesos para envolver el contador a -32.643.
2. Preparas el heap midiendo asignaciones con sysctl(KERN_MALLOCSTATS).
3. Ganas la carrera con IPC_RMID mientras otro proceso adjunta un segmento con el tamaño confundido.

4. Alineas asignaciones de sockets IP con IP_MULTICAST_TTL=2 para crear una estructura persistente de 16 bytes, y usas una escritura fuera de límites de -1 para pisar sus contadores.

5. Cierras el socket, los decrementos atómicos tocan dos veces el mapeo auto-referente de la PTE, lo cambian de modo usuario a modo supervisor... y ya tienes ejecución de código en kernel. Shell de root. Fin. 💥

Lo impresionante no es el bug: es quién lo tenía

OpenBSD es la referencia de seguridad del mundo libre. Auditoría de código fuente a mano, APIs inseguras eliminadas, ASLR, W^X, separación de privilegios, sandboxing, KARL. Si tu servidor no puede con esto, no puede con nada.

Y aun así, un short de 16 bits con 37 años de antigüedad le dio la vuelta. Los problemas ya están corregidos en las erratas 026 y 018 de OpenBSD, pero el detalle revelador está en el análisis: los asignadores de memoria del kernel son deterministas.

Las direcciones base no se aleatorizan, así que las estructuras tempranas del boot caen siempre en el mismo sitio. Con punteros de función dentro, son dianas fijas. FreeBSD y NetBSD al menos ya implementan safe-unlinking en su sys/queue.h; OpenBSD, según el investigador, aún no.

La lección que va más allá de OpenBSD

Calif insiste en un punto incómodo: vivimos en la era del descubrimiento de vulnerabilidades asistido por IA. Lo que antes tomaba años de auditoría humana, ahora encuentra herramientas automáticas en semanas — de hecho, esta misma semana otro modelo de IA localizó bugs de 27 años en kernels de OpenBSD y Linux.

La defensa ya no puede ser "auditar más". Puede ser neutralizar clases enteras de ataques: bounds sanitizer en compilación (Calif reportó 21 bugs a FreeBSD que esa función habría cazado), aleatorizar la PTE, hacer no determinista el asignador. Subir la vara para que el siguiente bug de 37 años no baste.

Tu servidor, ¿corrige sus erratas de seguridad el mismo día que salen o cuando alguien explota el bug? Para la mayoría de equipos la respuesta da miedo.

📱 Comparte esto con alguien que jura que "su sistema no tiene agujeros" — y déjame en los comentarios: ¿usás OpenBSD, FreeBSD o ya te mudaste a Linux por comodidad?