OpenBSD tiene un use-after-free que permite la escalada local de privilegios a root

Artículo original ↗ Discusión en Hacker News ↗

Vulnerabilidad e impacto

  • La CVE describe un use-after-free en sys/kern/sysv_sem.c (semaphores SysV) en OpenBSD ≤7.9 que permite la escalada local de privilegios (LPE) a root.
  • Es un UAF de cambio de contexto después de tsleep en sys_semget().
  • Los comentaristas subrayan que es grave, pero no un “agujero remoto”.
  • Se debate su accesibilidad desde procesos aislados; una implementación de pledge(2) enlazada sugiere que los demonios base aislados generalmente no pueden usar estas syscalls.

Descubrimiento y auditoría asistida por IA

  • El error parece haber sido descubierto en la iniciativa “Patch The Planet” (modelos de OpenAI + Trail of Bits) escaneando proyectos de código abierto.
  • Algunos infieren que primero se corrigió como un error genérico; solo más tarde se reconoció su potencial de LPE, posiblemente por la herramienta de IA. Esto se presenta como una suposición, no como algo confirmado.
  • Estadísticas propias de Patch The Planet: Linux 24 LPEs, FreeBSD 7, OpenBSD 1, además de muchos problemas no LPE.
  • Debate sobre si las auditorías basadas en IA son rentables frente a financiar investigación de seguridad tradicional.

Récord de seguridad de OpenBSD y “marketing”

  • El eslogan de OpenBSD de “solo dos agujeros remotos en la instalación por defecto” es a la vez elogiado por ser técnicamente exacto y criticado por selectivo:
    • La instalación por defecto es mínima y tiene la mayoría de los servicios deshabilitados, así que los sistemas del mundo real difieren.
    • Aun así, los valores predeterminados mínimos y el endurecimiento agresivo (pledge, unveil, W^X, ASLR, etc.) se consideran fortalezas reales.
  • Algunos sostienen que OpenBSD a veces minimiza o filtra lo que etiqueta como “fallos de seguridad”, en parte porque muchos problemas reportados están sobreexagerados o son poco prácticos.

Comparaciones con Linux/FreeBSD y tamaño del código

  • Varios comentaristas relacionan más errores en Linux/FreeBSD con:
    • Bases de código más grandes y más características/controladores.
    • Mayor rotación de desarrollo.
  • Se citan comparaciones de líneas de código; menos LOC se asocia con menos errores, aunque las implicaciones exactas para la seguridad se discuten.

Relevancia de la escalada local de privilegios

  • Una postura: las LPE importan menos para los despliegues típicos de servidores OpenBSD que no ejecutan código no confiable.
  • Contraargumento: las LPE se vuelven críticas cuando se encadenan con RCE o ataques a la cadena de suministro; son clave en la defensa en profundidad.

Discusión sobre Rust y la seguridad de memoria

  • Muchos señalan que el modelo de propiedad de Rust está diseñado para evitar UAF, así que una versión directa de este error probablemente no compilaría.
  • Otros enfatizan la realidad del kernel:
    • Grandes partes deben ser unsafe, especialmente alrededor de interrupciones, DMA y primitivas de bajo nivel.
    • La seguridad del Rust “seguro” depende de la corrección del código unsafe subyacente.
  • Consenso: Rust reduce significativamente ciertas clases de errores, pero no elimina mágicamente las vulnerabilidades del kernel.

Compromisos de diseño y características de OpenBSD

  • Varios argumentan que el buen resultado de OpenBSD (una LPE) refleja cultura, ingeniería cuidadosa y un conjunto de funciones deliberadamente limitado.
  • Hay debate sobre si OpenBSD es realmente “mínimo”:
    • Algunos dicen que omite subsistemas importantes (por ejemplo, Bluetooth, sistemas de archivos “modernos” como ZFS) en parte por razones de seguridad y mantenimiento.
    • Otros señalan que el sistema base en realidad es rico (por ejemplo, demonios BGP, herramientas de red), solo que con una filosofía y un alcance distintos.
  • Se cuestiona la falta de journaling/ZFS para routers; los defensores apuntan a FFS totalmente síncrono y preguntan qué datos de un router realmente deben sobrevivir a una pérdida de energía.

Herramientas de DNS y tangente de OpenWRT

  • Una rama separada del hilo critica el historial reciente de vulnerabilidades de dnsmasq; algunos lo han eliminado de sus sistemas.
  • Se cuestiona el uso por defecto de dnsmasq en OpenWRT; se sugieren alternativas como Unbound (con o sin NSD), pero el papel “todo en uno” de dnsmasq como DNS/DHCP/BOOTP/TFTP hace que reemplazarlo no sea trivial.