Exploit encadena un bug de 37 años y da root en OpenBSD 7.9

Root en OpenBSD 7.9, con relinking de KARL, SMAP y SMEP activados, y sin ningún fallo de filtración de información que ayude. Eso es lo que demostró esta semana la firma de seguridad Calif, según su investigación publicada, y el punto de entrada es un desbordamiento de entero que llevaba unos 37 años en el código de memoria compartida de BSD.

Antes de que lluevan los chistes sobre OpenBSD, seamos precisos sobre quién paga la factura. Esto es una escalada local de privilegios, no un agujero remoto: el atacante necesita primero ejecución de código como usuario sin privilegios. Así que la factura llega a quien ejecute sistemas OpenBSD multiusuario, servidores de compilación compartidos, servicios enjaulados o cualquier entorno donde una cuenta local hostil es la suposición de trabajo y no la excepción. Si ese es tu caso, se acabó la era de tratar los parches de escalada local como mantenimiento de segunda categoría.

Un contador de 16 bits de la era Reagan

El fallo es casi insultante por su simplicidad. En las fuentes BSD originales, el contador de adjuntos de memoria compartida —shm_nattch— se definía como un short de 16 bits con signo. Su máximo es 32.767. Calif descubrió que bifurcar repetidamente un proceso con registros de adjunto de memoria compartida podía empujar el contador más allá de ese techo, haciendo que diera la vuelta a un valor negativo. Ese desbordamiento de entero, combinado con una condición de carrera, produce un use-after-free.

OpenBSD, un proyecto cuya marca entera es la auditoría proactiva, arrastró este fósil aritmético durante décadas. Un comentarista del hilo de Hacker News señaló que el código equivalente de NetBSD se corrigió por accidente durante una reescritura en agosto de 1999. Por accidente. Nadie lo encontró a propósito; simplemente se coló en una refactorización. Ese detalle importa más que cualquier primitiva de explotación del informe, porque muestra los límites de la revisión de código como control. Audita todo lo que quieras: un short con signo que nadie tenía motivos para tocar desde los años ochenta no parece una superficie de ataque hasta que alguien hace la pregunta incómoda.

OpenBSD corrigió el desbordamiento y el segundo fallo, una escritura fuera de límites separada en el kernel, en las erratas 026 y 018 respectivamente, y Calif publicó el código de prueba de concepto completo tras la distribución de las correcciones, informó The Hacker News. Así que el parche existe antes que el exploit público. Eso es la cadena de suministro funcionando como debe. Ahora la parte que debería poner nerviosa tu cola de parches.

La cadena es el producto, no los bugs

Por separado, eran dos fallos locales del tipo que se registran, se corrigen y se olvidan. Encadenados, atraviesan tres de las mitigaciones insignia de OpenBSD sin una sola filtración de información. La secuencia, según el informe de Calif, es una pequeña clase magistral de economía del heap:

1. Mapear 127 segmentos de memoria compartida SysV, desmapearlos con munmap() y luego bifurcar 259 procesos para hacer dar la vuelta al contador de adjuntos hasta -32.643.
2. Preparar el heap usando las métricas del asignador de sysctl(KERN_MALLOCSTATS) para detectar cuándo aparecen nuevas páginas.
3. Ganar una carrera entre IPC_RMID en un proceso y un adjunto con confusión de tamaño en un proceso auxiliar.
4. Usar un socket IP con IP_MULTICAST_TTL establecido a un valor no predeterminado para colocar una estructura ip_moptions persistente de 16 bytes junto al objetivo.
5. Disparar la escritura condicional de -1 fuera de límites para corromper los contadores de membresía, y luego close() el socket para que la ruta de limpieza decremente dos veces memoria elegida por el atacante: al cambiar el mapeo autorreferencial de PTE de usuario a supervisor, se anulan SMAP/SMEP y se sobrescribe un puntero predecible del kernel para obtener root.

Ninguno de esos pasos exige vencer la aleatorización por fuerza bruta, y eso es lo incómodo. KARL reubica el binario del kernel para aleatorizar las direcciones de funciones y datos, pero, como señala Calif, los asignadores de memoria del kernel siguen siendo deterministas. Las asignaciones del arranque temprano caen en los mismos lugares en el mismo hardware, en cada arranque. El exploit simplemente apunta a las estructuras predecibles que contienen punteros a funciones, en este caso los manejadores de ioctl de lo0 y enc0, sobrescribiendo uno para controlar el flujo y usando el otro para restaurar el puntero después.

Lo que realmente compras con «seguro por defecto»

Esta es la pregunta que tu consejo debería hacerse, y no es si OpenBSD es inseguro ahora. Es esta: ¿qué compraron realmente las mitigaciones? KARL, SMAP y SMEP elevaron el coste de explotación de un solo fallo a dos fallos más semanas de preparación especializada del heap. Eso es valor real. También es un valor finito, porque la aritmética del encadenamiento de exploits es brutal: la fortaleza de la mitigación multiplica el esfuerzo del atacante, pero el número de fallos lo divide. Dos fallos locales mediocres en una misma base de código equivalen a una shell root.

Hemos visto las mismas matemáticas en el lado ofensivo hace poco: cuando Xbow gastó 40.000 dólares en cómputo de IA para construir una cadena de exploits para Chrome, la lección no fue que Chrome esté roto, sino que encadenar es una partida presupuestaria, y los presupuestos siguen bajando. Un investigador humano encadenando un desbordamiento de 37 años hoy es un flujo de trabajo que una herramienta automatizada intentará contra todo tu parque mañana. El tiempo para encadenar es la métrica a vigilar, no el recuento de CVE.

Para su mérito, Calif no se detuvo en el trofeo. Su informe propone endurecimientos concretos: comprobaciones de desvinculación segura en listas doblemente enlazadas (que FreeBSD y NetBSD ya implementan en sys/queue.h), aleatorizar la dirección del mapa PTE autorreferencial en el arranque usando un byte aleatorio para elegir una ranura PML4, y hacer no determinista el asignador del kernel. Que OpenBSD los adopte es una cuestión de recursos, no técnica: las implementaciones ya estaban esbozadas en el mismo documento.

Qué cambia para los defensores esta semana

Primero, aplica las erratas 026 y 018. Obvio, pero dilo igualmente: la ventana entre el PoC público y la ejecución de tus parches es el único periodo que importa, y esa ventana ya está abierta.

Segundo, reordena la escalada local en tu política de parches. La mayoría de las organizaciones priorizan por explotabilidad remota y dejan que los fallos locales del kernel esperen a la siguiente ventana de mantenimiento. El encadenamiento invierte esa lógica en cualquier host donde se ejecute código no confiable: runners de CI, shells compartidas, hosts de contenedores, cualquier cosa con usuarios locales en los que no confíes del todo. Si no puedes afirmar con seguridad qué cuentas pueden ejecutar código en una máquina concreta, tu exposición real es el escenario de encadenamiento, no el CVE aislado.

Tercero, dedica un momento al control más barato. La memoria compartida SysV es un mecanismo IPC de décadas; en muchos sistemas modernos nada legítimo lo usa. Restringir o auditar su uso, y vigilar tasas patológicas de fork() desde procesos individuales, cuesta una fracción de un incidente. El control caro, es decir, las mitigaciones que obligan a los atacantes a encadenar, ya hizo su trabajo al poner esto difícil. El barato consiste en asegurarse de que nadie pueda siquiera intentarlo.

Mi veredicto: esto importa, pero no porque se haya caído el halo de OpenBSD. Importa porque es una demostración clara de que la reputación de auditoría y las capas de mitigación son calendarios de amortización, no garantías. Hay errores más antiguos que algunos de tus ingenieros que siguen sosteniendo tu kernel. Parchea en este ciclo, reprioriza la escalada local y deja de pagar por «auditado» como si fuera un estado final en lugar de una suscripción recurrente.