30 julio 2009

Grave vulnerabilidad en Bind 9 con exploits publicados

¿Tienes un servidor DNS Bind 9 instalado en alguna de tus máquinas que administras, que no corresponde ni con la versión 9.4.3-P3, 9.5.1-P3 ni la 9.6.1-P1? Pues deja todo lo que estés haciendo.

El 28 de Julio podíamos leer en la página del ISC un advisory sobre una vulnerabilidad que afectaba al servidor Bind, versión 9, con la que se puede provocar una denegación de servicio al sistema dónde se encuentre instalado (que no son pocos en todo el mundo).

La vulnerabilidad afecta a la función dns_db_findrdataset() que se encuentra en el fichero db.c, y que según explica el advisory, falla en caso de que el mensaje de actualización dinámica contenga un registro de tipo "ANY" y si por lo menos un registro RRSet para ese FQDN (Fully Qualified Domain Name) existe ya en el servidor."

Lo más grave de todo es que ya existen exploits públicos que se aprovechan de esta vulnerabilidad. En SecurityFocus podemos encontrarnos este txt que explica como explotar el fallo, y en la lista de seguridad Full-Disclosure, KingCope (el que descubrió no hace mucho el fallo de bypass en WebDav del que os hablamos por aquí) ha publicado una versión del exploit en C.

Así que no hay excusa, hay que actualizar YA de YA.

6 comments :

KNO dijo...

No tengo mucha idea de esto, pero ¿para ejecutar el ataque hay que lanzar una actualización al bind con una clave válida o vale con lanzar la actualización sin más?
Es decir, por lo que ve en el exploid:
our $NSI = 'dns server';
our $NSI_KEY_NAME = 'key name';
our $NSI_KEY = 'key';

y lo poco que se, para realizar una actualización DNS te pide una key. ¿El ataque es válido si no sabes la key? Y por consiguiente ¿si se lanza el ataque, queda registro de qué key lo realizó y puedes cortarle los colgajos al dueño de esa key?

José A. Guasch dijo...

Mira este hilo en la lista de OSS-Security:

http://www.openwall.com/lists/oss-security/2009/07/28/8

No siempre es necesaria la key para realizar la actualización DNS.

KNO dijo...

Yo he probado en mi server con:
our $NSI = '127.0.0.1';
our $NSI_KEY_NAME = 'X';
our $NSI_KEY = 'X';


my $rzone = 'prueba.kno';
my $rptr = "1.$rzone";

con bind-9.6.0-5.1mdv2009.1 y bind sigue funcionando.

José A. Guasch dijo...

Has tenido suerte, justamente ese bind de Madriva ya está parcheado!

http://seclists.org/fulldisclosure/2009/Jul/0500.html

Busca en Updated Packages

Anónimo dijo...

Una configuración habitual es poner el/los dns secundario como slave del primario por lo que mientras se actualiza, aunque caigan los primarios (master) seguirá habiendo servicio con los secundarios (slaves) ;)

RuBiCK dijo...

Una configuración habitual es poner el/los dns secundario como slave del primario por lo que mientras se actualiza, aunque caigan los primarios (master) seguirá habiendo servicio con los secundarios (slaves) ;)