BIND 9 corrige 14 fallos y uno tumba el servidor por DoH sin autenticarse

El Internet Systems Consortium (ISC) ha sacado BIND 9.20.29 y 9.21.26 para tapar catorce vulnerabilidades en su servidor DNS de codigo abierto, divulgadas el 16 de septiembre. Una de ellas afecta a cualquier servidor que responda DNS-over-HTTPS y permite tumbar el proceso named con una sola peticion: se manda una firma SIG(0) invalida y se cierra la conexion antes de que named acabe de comprobarla. Sin credenciales de ningun tipo. ISC afirma que no tiene constancia de que ninguna de las catorce se haya explotado.

Las versiones que arreglan que: 9.20.29, en la rama estable, corrige las catorce. 9.21.26, en desarrollo, corrige trece, porque CVE-2026-19662 no afecta a la 9.21. Y 9.20.29-S1, la Supported Preview Edition para clientes con soporte, las corrige todas. ISC no documenta workaround para ninguna.

Doce de las catorce tambien afectan a la rama 9.18, hasta la 9.18.50 inclusive, que fue su ultima publicacion. El soporte de 9.18 termino a finales de junio y no hay ninguna version de esa rama que las arregle. ISC ya aviso en mayo de que quien siguiera en 9.18 planificara el salto a 9.20 cuanto antes. Su matriz de vulnerabilidades anade que a las versiones EOL hay que suponerlas vulnerables a los CVE nuevos.

Que necesita el atacante

Dos de las catorce se disparan solo con una peticion, sin que el atacante tenga que montar su propio servidor DNS, y ambas van contra las ramas 9.20 y 9.21. La del DoH es CVE-2026-77692. La otra, CVE-2026-76163, tumba named con una consulta de tipo TKEY cuando el named.conf no tiene bloque global de options.

El resto de caidas requieren un resolutor recursivo, de los que resuelven nombres por cuenta de los clientes, que reciba datos fabricados desde un servidor en manos del atacante. Una sola respuesta preparada tumba un resolutor con configuracion por defecto (CVE-2026-19667), uno que use dns64 con break-dnssec yes (CVE-2026-19666), o un resolutor validador que reciba una respuesta comodin con pruebas NSEC y NSEC3 a la vez (CVE-2026-80274). CVE-2026-19662 necesita un orden y un timing concretos de respuestas, y no toca la 9.21.

Otras cuatro no tumban nada: consumen CPU o memoria del resolutor, dos de ellas a traves de registros de alias SVCB/HTTPS en cache (CVE-2026-81563 y CVE-2026-81736). ISC puntua siete de las catorce como High, todas con 7,5 en CVSS 3.1. Las otras siete son Medium, entre 5,3 y 6,5.

Integridad de datos y transferencias

Las cuatro ultimas van contra lo que el servidor sirve o el resolutor acepta. Dos permiten que un resolutor validador acepte la prueba DNSSEC equivocada: con CVE-2026-19941, un NSEC firmado de una zona sin relacion pasa por prueba de que no existe un comodin; con CVE-2026-77119, un NSEC3 firmado de una zona hermana pasa por prueba de que una delegacion no esta firmada. En ambos casos ISC habla de envenenamiento de cache, y hacen falta condiciones sobre donde se situa el atacante.

CVE-2026-19033 toca al secundario que copia una zona de un primario y solo acepta transferencias firmadas con TSIG: durante un IXFR de varios mensajes por TCP, named podia empezar a servir los datos nuevos antes de que llegara el mensaje final con la firma, y no revertia si esa firma no aparecia nunca. El arreglo exige TSIG en cada mensaje de la transferencia entrante, algo que los servidores modernos ya hacen, segun ISC. CVE-2026-78301 pide mas acceso: una zona malformada cargada en un autoritativo, por ejemplo via transferencia, con un nodo NS o DNAME por encima de su propio origen se trata como corte de zona y las consultas devuelven una delegacion fuera de zona.

Queda el detalle incomodo de los paquetes de distribucion. Debian 12 lleva un paquete basado en 9.18.49 y su security tracker no listaba ninguna de las catorce a las 06:20 UTC del 17 de septiembre. Quien administre un resolutor o un autoritativo con DoH expuesto tiene motivo para mirar la version hoy mismo; esperar al parche de la distribucion no vale si la rama en la que se basa ya no recibe arreglos.