Un contador de 16 bits con 37 años de antigüedad abrió la puerta a root
Calif, una firma de investigación ofensiva, publicó cómo consiguió una shell de root en OpenBSD con KARL, SMAP y SMEP activados y sin necesidad de una vulnerabilidad de divulgación de información. El punto de partida es casi arqueológico: el contador de adjuntos de memoria compartida (shm_nattch) fue definido como un short de 16 bits con signo, y esa decisión se remonta unos 37 años atrás, a las fuentes originales de BSD.
El fallo se corrigió en los errata 026 y 018 de OpenBSD. Calif reportó las vulnerabilidades a principios de año, junto con parches sugeridos para el proyecto.
Cómo se encadena: del desbordamiento a la shell de root
El exploit no depende de un solo error. La cadena, según la descripción técnica de Calif, funciona así:
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días- Mapear 127 segmentos de memoria compartida SysV, desmapearlos con
munmap()y hacerforkde 259 procesos para llevar el contador de adjuntos a -32.643. - Hacer heap grooming con métricas de
sysctl(KERN_MALLOCSTATS)(kb_totalykb_totalfree) para saber cuándo se asignan páginas nuevas. - Ganar la condición de carrera usando
IPC_RMIDen un proceso mientras un proceso auxiliar adjunta un segmento de memoria compartida con tamaño confundido. - Alinear asignaciones de sockets IP y fijar
IP_MULTICAST_TTLen 2 para reservar unstruct ip_moptionspersistente de 16 bytes, cuya última palabra empaqueta dos contadores de 16 bits. - Disparar la escritura fuera de límites condicional (
-1) para sobrescribir los campos de número y máximo de membresías. - Cerrar el socket para recorrer los miembros del grupo, lo que modifica dos veces el mapeo autorreferencial de PTE y lo pasa de accesible por usuario a accesible por supervisor.
- Ejecutar código en kernel sobrescribiendo un puntero predecible y restaurarlo después para obtener la shell.
En resumen: el desbordamiento entero habilita un use-after-free por condición de carrera y, combinado con una escritura fuera de límites separada en el kernel, deriva en escalada local de privilegios hasta root.
Por qué el kernel de OpenBSD sigue siendo un objetivo de alto valor
OpenBSD se construyó sobre auditoría de código, reemplazo de APIs inseguras, separación de privilegios, sandboxing, ASLR y W^X. Ese historial es real y es la razón por la que el proyecto marca el estándar del endurecimiento en sistemas tipo Unix.
Pero el hallazgo de Calif muestra dónde queda el hueco: KARL reenlaza el binario del kernel para aleatorizar direcciones de funciones y datos, pero los asignadores de memoria del kernel siguen siendo deterministas. Ni el asignador de arranque ni el best-fit aleatorizan su dirección base, así que las asignaciones tempranas caen en ubicaciones predecibles entre reinicios en el mismo hardware.
Cuando esas estructuras predecibles contienen punteros a funciones, se vuelven blancos ideales. El exploit apunta de forma fiable a los manejadores ioctl de lo0 y enc0: sobrescribe uno para tomar el control de flujo y usa el otro para restaurar el puntero original.
¿La IA está acelerando este tipo de hallazgos?
El propio Calif cierra su análisis hablando de «la era del descubrimiento de vulnerabilidades asistido por IA». Los números de 2026 respaldan esa preocupación.
Microsoft reportó que su laboratorio FORGE ayudó a descubrir vulnerabilidades de Windows a las que se asignaron 140 CVE entre mayo y septiembre de 2026, incluidas 52 solo en la actualización de seguridad de septiembre. En el mismo período, FORGE envió 155 reportes validados internamente en 23 proyectos de código abierto, de los cuales 93 ya tenían reconocimiento o aceptación documentada de los mantenedores.
El costo también bajó. Según Microsoft, generar una prueba de concepto para 182 hallazgos de fallos confirmados costó en promedio US$3,61 en uso de modelos y 21,5 minutos; probar potencial de escalada local de privilegios en seis casos seleccionados promedió US$8,56 y 25,4 minutos.
Wired documentó la otra cara de la misma ola: Microsoft emitió parches para 974 CVE en un solo mes, un récord; Oracle pasó de 309 parches en julio de 2025 a 1.448 en julio de 2026; y el proyecto cve.icu registró 66.401 CVE en lo que iba del año, frente a 33.512 a la misma altura del año anterior.
El matiz importante lo puso TechTarget: solo alrededor del 1% de las vulnerabilidades atribuidas a descubrimiento asistido por IA aparecían como explotadas en el mundo real a junio de 2026, según el análisis del investigador Patrick Garrity. Pero las que sí se explotan son más peligrosas: el 50% de las vulnerabilidades descubiertas por IA derivaron en ejecución remota de código, frente al 26% de las encontradas por humanos o escáneres convencionales, según Google Threat Intelligence Group.
Qué mitigaciones propone Calif
Además de los errata ya publicados, Calif plantea cuatro líneas de trabajo:
- Safe-unlinking: verificar los invariantes de la lista doblemente enlazada antes de escribir. FreeBSD y NetBSD ya lo tienen implementado en su
sys/queue.h. - Aleatorizar la dirección del mapa autorreferencial de PTE, usando un byte aleatorio en
.openbsd.randomdatapara elegir un slot de PML4 en el arranque. - Hacer no determinista al asignador del kernel, aleatorizando la dirección base de las asignaciones y también el orden de asignación en tiempo de ejecución.
- Aprovechar el compilador: el array bounds sanitizer, un subconjunto del Undefined Behaviour sanitizer, elimina accesos fuera de límites en arrays de tamaño fijo. Calif sugirió a FreeBSD habilitarlo en builds de release y reportó de forma privada 21 problemas que ese sanitizador habría detectado, algunos con impacto de escalada local de privilegios. También menciona Alloc Tokens, una función del compilador que aísla las asignaciones con punteros de las que no los contienen.
Qué significa esto para tu startup
1. Un sistema operativo «seguro por diseño» no es un sistema operativo parchado. Si tienes appliances, firewalls, VPN gateways o routers corriendo OpenBSD, verifica hoy si están cubiertos por los errata 026 y 018. La escalada es local, así que el riesgo real aparece cuando un atacante ya tiene un pie dentro de tu red.
2. La deuda técnica heredada no caduca. Este bug vivió 37 años en el código. Revisa los tipos de datos de tus propios contadores y estructuras de conteo: un short donde debería haber un int o un uint64 es exactamente el mismo error, en tu stack.
3. Presupuesta capacidad de parcheo, no solo de detección. Con el volumen de CVE creciendo, el cuello de botella se movió. Como resume el investigador Jerry Gamblin en Wired: «el descubrimiento escala con el cómputo; la remediación escala con personas, y las personas son la parte que no puedes comprar más en un trimestre». Si tu equipo no tiene un proceso claro para priorizar y aplicar parches, el volumen actual lo va a desbordar.
4. Adopta sanitizadores en tu CI. El array bounds sanitizer y herramientas similares atrapan clases enteras de errores antes de que lleguen a producción. Es más barato activarlos que explotarlos.
Conclusión
El caso de Calif es un recordatorio incómodo: la seguridad no es un estado que se alcanza, es una carrera que se corre. OpenBSD lleva décadas poniendo el estándar en endurecimiento proactivo, y aun así un contador de 16 bits heredado de las fuentes originales de BSD encontró su camino hacia una shell de root. Para un founder, la lección práctica es doble: parchea lo que ya tienes en producción y trata la deuda técnica de tipos y límites como lo que es, un riesgo de seguridad con fecha de vencimiento desconocida.
Fuentes
- Big Fish: Exploiting a 37-Year-Old Kernel Bug in OpenBSD (fuente original)
- 3 lessons from frontier AI vulnerability research (Microsoft Security)
- AI-discovered flaws are rarely exploited but pose greater risk (TechTarget)
- Forget the AI Slowdown—the Vulnerability Explosion Is Already Happening (Wired)
¿Y esto cómo se aplica en tu negocio?
En CAR, dueños de empresa de Latinoamérica y España usan la tecnología para ser más rentables. Empiezas con una ruta de 7 días y terminas con un sistema funcionando en tu negocio.
👥 Probar 7 días
