CERT publica CVE para 6 vulnerabilidades críticas de seguridad en dnsmasq

 (lists.thekelleys.org.uk)
1 puntos por GN⁺ 2 시간 전 | 1 comentarios | Compartir por WhatsApp
  • CERT publicará el 11 de mayo de 2026 un conjunto de CVE para 6 vulnerabilidades críticas de seguridad en dnsmasq
  • Todas las vulnerabilidades son bugs antiguos y afectan a casi todas las versiones de dnsmasq, excepto algunas muy antiguas
  • Los CVE se revelaron previamente a los proveedores, y cada proveedor debe distribuir a tiempo una versión parcheada del paquete dnsmasq
  • Se creó 2.92rel2, que aplica los parches a la versión estable dnsmasq 2.92, y puede descargarse desde la ubicación habitual
  • Pronto se creará la etiqueta dnsmasq-2.93rc1, y tras las pruebas se apunta a lanzar la versión 2.93 en aproximadamente una semana

Divulgación de vulnerabilidades y parches de dnsmasq

  • CERT publicará el 11 de mayo de 2026 un conjunto de CVE para 6 vulnerabilidades críticas en dnsmasq
  • Todas las vulnerabilidades son bugs antiguos y aplican a casi todas las versiones de dnsmasq, excepto algunas muy antiguas
  • Los CVE se revelaron previamente a los proveedores, y cada proveedor debe distribuir a tiempo una versión parcheada del paquete dnsmasq
  • Los detalles y parches pueden consultarse en https://thekelleys.org.uk/dnsmasq/CVE/
  • Se creó 2.92rel2, que aplica los parches a la versión estable dnsmasq 2.92, y puede descargarse desde la ubicación habitual
  • También se subirán commits de corrección al árbol de desarrollo al mismo tiempo; algunos usan los mismos parches que los backports y otros son reescrituras más amplias que abordan la causa raíz

Aumento de reportes basados en AI y plan para 2.93

  • En los últimos meses han aumentado mucho los reportes de bugs impulsados por investigación de seguridad basada en AI, y eliminar duplicados y clasificar bugs ha requerido mucho tiempo
  • Los bugs se dividieron entre los que requerían divulgación previa a proveedores y los que convenía corregir de inmediato tras hacerse públicos; esta distinción es inevitablemente subjetiva
  • Dado que varios “good guys” encontraron repetidamente los mismos bugs, se considera posible que los “bad guys” también los hayan encontrado, por lo que no se ve mucha eficacia en un embargo largo
  • Coordinar embargos y ofrecer backports requiere mucho tiempo y esfuerzo de todos los participantes
  • La prioridad es corregir la mayoría de los bugs en próximas versiones para dejar nuevas releases de dnsmasq lo más libres de errores posible
  • El hecho de que en las semanas previas al anuncio hayan llegado muchos commits de corrección de seguridad al repositorio git también va en esa dirección
  • Pronto se planea crear la etiqueta dnsmasq-2.93rc1, y el objetivo es publicar la versión estable 2.93 lo antes posible
  • Probar la release candidate es importante, así que quienes puedan deberían probarla cuanto antes
  • Si todo avanza sin problemas, 2.93 podría salir en aproximadamente una semana
  • El “tsunami” de reportes de bugs generados por AI no muestra señales de detenerse, por lo que es posible que el mismo proceso vuelva a repetirse pronto
  • Existe una tensión entre incorporar en 2.93 la mayor cantidad posible del flujo actual de bugs y lanzarlo a tiempo, y la prioridad está en una release oportuna

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 시간 전
Comentarios en Hacker News

  • Parece que ya estamos en un punto de inflexión donde se vuelve urgente cambiar el código escrito en C a lenguajes con seguridad de memoria
    La mayoría de las vulnerabilidades que se descubren últimamente están directamente relacionadas con lenguajes sin seguridad de memoria, y parece muy difícil justificar que no se pueda escribir un servidor DNS/DHCP en Rust o Go, idealmente sin unsafe

    • https://news.ycombinator.com/item?id=47943499 — hubo un caso donde intentaron reemplazar coreutils con una nueva implementación en Rust y salieron 44 CVE. No hay almuerzo gratis
    • El problema no es el lenguaje, sino la falta de talento para hacer este trabajo
      Los investigadores de seguridad con IA al menos están haciendo algo. Si reescribir todo en Rust fuera tan fácil, al día siguiente de un incidente así ya habría aparecido un reemplazo sólido en Rust
      No pasa porque hacer este tipo de trabajo no te da estrellas en GitHub
    • Quizá el problema sea la forma en que vemos la memoria dinámica
      Dudo que realmente sea cierto eso de “como no conocemos el tamaño máximo, todo debe ser dinámico”. Que un programa declare el tamaño máximo aceptable de entrada y, si se excede, falle o use un búfer circular, no es precisamente el fin del mundo
      Si puedes conocer el tamaño, puedes diseñar en torno a eso. La RAM es finita, y es raro que todas las capas dentro de ella estén diseñadas como si fueran infinitas
      Cambiar a Rust parece una enorme pérdida de tiempo y no resuelve el problema de fondo: que no se modela el programa según la realidad de los recursos finitos del sistema. Y no es solo un problema de memoria. Casos como Chrome metiendo un modelo de 4 GB en el dispositivo del usuario son parecidos
    • No estoy de acuerdo. Gracias a los agentes de IA que buscan vulnerabilidades potenciales, las defensas claramente están mejorando

  • https://xchglabs.com/blog/dnsmasq-five-cves.html

  • Tenía curiosidad por saber si OpenWRT ya había sacado una nueva compilación, y la respuesta es que todavía no, pero están en eso
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • Mi MaraDNS ha sido auditado bastante a fondo al entrar en la era de las auditorías de seguridad asistidas por IA
    Desde 2023 no se ha encontrado ni un solo bug de seguridad serio [1]
    Lo único que encontraron los auditores fue algo como “cuando Deadwood está en modo totalmente recursivo y recibe un paquete extraño, tarda más de lo normal en liberar recursos” [2], o “una utilidad auxiliar incluida en MaraDNS ni siquiera compilaba desde 2022, pero tiene un desbordamiento de búfer solo cuando $HOME supera los 50 caracteres” [3]
    Personalmente me deja muy satisfecho que MaraDNS parezca bastante seguro ahora que está recibiendo auditorías de seguridad reales y profundas
    [1] https://samboy.github.io/MaraDNS/webpage/security.html
    [2] https://github.com/samboy/MaraDNS/discussions/136
    [3] https://github.com/samboy/MaraDNS/pull/137

    • Si Lua 5.1 fue empaquetado con Lunacy en vez de cargarse como biblioteca, y además era la versión de 2012, probablemente también podría verse afectado por CVE-2014-5461 y otros
      Lua tampoco estuvo exento de correcciones de seguridad
    • Aun así, MaraDNS es mucho menos popular que dnsmasq
      Yo también tengo unas cuantas bibliotecas que escribí yo mismo, y desde 1991 no se ha encontrado ni un solo bug de seguridad serio en ellas. Claro, nadie usa mis bibliotecas
      No es por quitar mérito, pero este tipo de afirmaciones es importante ponerlas en contexto junto con el tamaño de la base de usuarios
    • Cuando configuré un servidor DNS hace tiempo, me alegró encontrar MaraDNS en lugar del enfoque “hace de todo” de dnsmasq y, más importante todavía, desde entonces no he tenido que preocuparme por él
    • Tengo curiosidad, pero no entiendo cuál es el punto aquí. ¿Que existe una alternativa a dnsmasq, o que su software de alguna manera es “mejor”?
      Esta autopromoción aporta muy poco a una discusión sobre dnsmasq
      Cuanto más usado es un software, más revisiones recibe y más bugs y casos límite se descubren
    • Bien hecho. Pero sigue sorprendiendo que incluso en 2026 se sigan escribiendo herramientas de red fundamentales en un lenguaje vulnerable como C

  • Menos mal que este software no se usa en millones de dispositivos que casi nunca reciben actualizaciones

    • Cuando el proveedor te dice que “no puede dejarte usarlo como quieres”, poder controlar tu propio hardware es algo bueno
    • Al menos, en la mayoría de los casos, esto corre en dispositivos donde el cliente no puede enviar paquetes hasta autenticarse primero en Wi‑Fi o conectarse físicamente al puerto Ethernet
    • ¿Y2K26?

  • Está bastante serio
    “Un atacante remoto que pueda hacer consultas DNS o responder DNS puede provocar una gran escritura fuera de límites en el heap”
    Una respuesta DNS malformada puede “provocar un bucle infinito que haga que dnsmasq deje de responder a todas las consultas”
    Solicitudes DHCP maliciosas pueden causar un desbordamiento de búfer

  • No todos los proyectos están recibiendo un tsunami de reportes de bugs generados por IA. Como se dijo arriba, MaraDNS no lo tuvo
    Supongo que djbdns y tinydns tampoco; si lo hubieran tenido, lo habrían anunciado a lo grande
    Nunca he entendido del todo por qué algunos proyectos se vuelven extremadamente populares y otros no
    Casi parece que las herramientas “demasiado peligrosas para hacerse públicas” escanean todos los proyectos, pero solo contactan de manera selectiva a los que tienen problemas. Así no tienen que admitir que su herramienta no encontró nada

    • Eso pasa con los proyectos populares

  • Nunca me ha gustado usar dnsmasq. Siempre me pareció que metía demasiadas cosas en una sola herramienta
    Siempre he preferido configurar por separado un resolvedor con caché local, un servidor DHCP y la configuración de arranque TFTP/PXE

    • Para algunos hay varias funciones de dnsmasq que son difíciles de reemplazar
      Por ejemplo, enviar consultas para *.example.com a un servidor upstream específico, devolver NXDOMAIN para sitios de phishing, o agregar todas las IP resueltas para *.example.org a un ipset para enrutamiento por políticas
      La última función incluso funciona en FreeBSD aunque BSD no tenga ipset. La lista *.example_xyz.com puede ser muy grande, y se dice que las versiones recientes de dnsmasq la manejan de forma eficiente
    • Por esa forma de pensar terminé usando MaraDNS para hosting DNS hace mucho tiempo
      10 de 10, sin arrepentimientos, totalmente recomendable
    • De acuerdo. También se siente un poco contrario a la forma “usual” de hacer las cosas en Linux
      Por ejemplo, Opnsense usa solo la parte DHCP de dnsmasq y usa unbound para DNS, y eso se siente un poco “raro”
    • Ese es en parte el objetivo. dnsmasq es una app de “hacer funcionar un router pequeño” metida en una sola caja
      DHCP y DNS están conectados, y PXE necesita entradas de DHCP. Si quieres una configuración simple, de otro modo tendrías que ensamblar al menos 3 demonios con sintaxis de configuración distintas

  • Esta es una pregunta de principiante para gente con más experiencia en el área, pero me pregunto por qué el software de este espacio no se escribe más seguido sobre runtimes como Erlang, con recolección de basura y concurrencia

    • La primera versión de dnsmasq salió en 2001. En ese momento, la lista de lenguajes realmente viables para servidores de red de alto rendimiento no era tan larga, y Erlang no estaba ahí
      La pérdida de rendimiento era demasiado grande, tenía un runtime opaco del que era difícil saber qué tan estable era entonces, había pocos contribuidores y también una huella de dependencias grande que no venía instalada en la mayoría de los sistemas
      Incluso cuando usé Erlang en sistemas de producción hacia 2015, si te salías un poco de su caso de uso original, todavía tenía asperezas. No es una crítica exclusiva de Erlang; muchos lenguajes y runtimes eran parecidos
      Muchos de estos sistemas que van a seguir recibiendo golpes durante las próximas semanas o meses tienen antecedentes parecidos. El kernel de Linux, por ejemplo, probablemente solo tenía como alternativa potencial C++. OpenSSL, otro habitual en problemas de seguridad, empezó en 1998
      Estoy totalmente de acuerdo con “no escriban proyectos nuevos con acceso a red en C”, pero si uno vuelve a 1998, es difícil decir qué otra opción era realmente práctica
      Había lenguajes más seguros, pero sus comunidades eran mucho más pequeñas y también era más difícil garantizar estabilidad. Java ya existía, pero no sé exactamente en qué momento se volvió un candidato serio para servidores de red; yo diría que hasta finales de los 2000. Lo que vi de Java en 1999 todavía no daba para eso
      Por ejemplo, en 2011 operé un servidor de red en Haskell para un uso relativamente poco importante, y colapsó bajo condiciones que ni siquiera eran tan extremas para una red de producción. En 2013 reutilicé la misma base de código sin cambios en el bucle principal de ejecución y mejoró como un 90%, así que creo que el problema era más de Haskell que mío
      Aun así, no era algo que yo metería en producción real, pero al menos mostró que no fue mi código el que falló. Eso quiere decir que, aunque Haskell existía en los 2000, difícilmente era una opción realista para servidores de red en esa época
      Ahora sí hay muchas más opciones que antes
    • En C, normalmente puedes mapear un struct directamente sobre un paquete de red, así que resulta bastante fácil
      En otros lenguajes muchas veces no es tan simple
      Claro, también está el hecho de que suelen ser más lentos y más pesados