El Error de openSSL en Debian subsanado dos años después

Menuda que se ha montado con el fallo detectado en el empaquetado del paquete openssl para distribuciones Debian y derivados, como Ubuntu. Al parecer tuvieron a bien comentar una inocente línea de código hace dos años que les daba unos errores molestos en código “no relacionado”, como bien comenta uno de los empaquetadores en el cambio en abril de 2006…

openssl (0.9.8a-9) unstable; urgency=low
[...]
* Don’t add uninitialised data to the random number generator. This stop
valgrind from giving error messages in unrelated code.
(Closes: #363516)

– Kurt Roeckx Thu, 6 Apr 2006 20:34:07 +0200

Esta cosa tan inocente consistía en comentar una llamada a una función de código que al parecer les daba un mensaje de error en alguna otra parte de código “no relacionado.” El caso es que justamente esta llamada es necesaria para que el proceso interno de generación de números aleatorios en la creación de claves asimétricas tipo RSA sea realmente aleatorio.

La línea 271 maldita comentada

La consecuencia de ello es que al no llamarse a esta función, la generación supuestamente pseudo-aleatoria de claves acaba siendo más predecible que el resultado de la selección española de fútbol en los mundiales y por tanto casi todas las parejas de claves públicas y privadas generadas por esta versión de openssl se pueden obtener por fuerza bruta. De hecho, desde debian.org se puede descargar un programa en perl, dowkd.pl.gz, de menos de 10 megas que contiene la lista de todas las claves que se han podido generar en estos dos años por este error y resulta trivial y rapidísimo buscar las claves de tu servidor SSH o del certificado del Apache. Para llorar un rato largo.

Por ahora, la lista de componentes, servicios y aplicaciones afectadas por este fallo es la siguiente,

• openssh, tanto usuarios como servidores
• OpenVPN
• DNSSEC
• material para claves para X.509
• encfs
• Tor
• postfix, exim4, sendmail y otras MTAs con SSL/TLS
• cyrus imapd
• courier imap/pop3
• dovecot con soporte imaps/pops
• apache2 (ssl certs)
• dropbear
• cfengine
• puppet
• xrdp
• tinc
• Certificados vsftpd SSL para FTPS
• Certificados proftpd SSL/TLS para FTPS
• DomainKeys (DK) y DKIM

Seguramente seguirá creciendo.

De la lista anterior, tenemos un servidor web, Apache, varios servidores de correo, tanto las MTAs que hablan SMTP como los servidores de acceso a los buzones de correo, servidores de ficheros TFP, protocolos de actualización de DNS y hasta el servicio tor de proxies anónimos de navegación.

A mi lo que me preocupa no es que los servidores de acceso remoto SSH se vean afectados, tanto en temas de posibles ataques de Man in the Middle o suplantación de partes. Lo que puede ser delicado es el asunto de los certificados digitales generados para servicios web o idenficar usuarios que se hayan creado a partir de openssl. Ya sean autofirmados o simplemente se haya creado una solicitud de certificado para ser firmada por una PKI externa, las parejas de claves van a estar comprometidas y puede desembocar esto en una oleada de revocaciones de certificados.

Por suerte tiro de EJBCA para jugar a las PKIs y no parece que Java o BouncyCastle hayan caído en la misma tentación simplificadora. Tan sólo se han visto afectados los servicios de openSSH y aparentemente los sensores y agentes del IDS Prelude la generación de las claves RSA la hacen a partir de /dev/random y están salvados.

Para la gente de Debian les ha supuesto de entrada deshabilitar el acceso por SSH y tirar todas las contraseñas de los usuarios actuales. A ver cuántos certificados digitales de servidores web caen por el camino, son revocados y renovados y sobre todo, a ver si se hace rápidamente.

Más de un administrador se lo debe de estar pasando en grande…

Veamos, si Terra lo único que es, bueno, era, un revendedor de ADSL de Telefónica y usa su infraestructura. Yo, como cliente de Terra voy a comprobar si tiran esas páginas. Aparentemente, el DNS falla. ¿Censura? Nada más lejos de la realidad. Lo que está pasando es que algún servidor DNS está caído. O bien los de Telefónica o bien alguno a los que se sincroniza. Si nos ponemos a mirar un poco más damos enseguida con el problema.

El asunto radica en que el Registrar de los dominios “censurados”, eNom inc. ha debido de tener un problema o bien en la sincronización o peticiones entre los DNS de Telefónica y los suyos algo ha ido mal y por eso para Telefónica esos nombres de dominio no se resuelven.

Vamos a usar un poco la maravillosa herramienta dig para arrojar algo de luz. Antes de nada, el escenario: mi casa. Como diría E.T. Tengo configurados los DNS de Telefónica 194.179.1.100 y 194.179.1.101. Si hacemos una petición a uno de los dominios afectados, como gamestorrents.com, vemos lo siguiente:

[code]theefrit@teroknor:/tmp$ dig @194.179.1.100 gamestorrents.com

; <<>> DiG 9.3.4 <<>> @194.179.1.100 gamestorrents.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26509
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gamestorrents.com. IN A

;; Query time: 90 msec
;; SERVER: 194.179.1.100#53(194.179.1.100)
;; WHEN: Tue Mar 27 18:12:41 2007
;; MSG SIZE rcvd: 35
[/code]

Parece que hay un fallo con los DNS, devuelve un SERVFAIL. Probemos ahora con otro, newpct.com:

[code]
theefrit@teroknor:/tmp$ dig @194.179.1.100 newpct.com

; <<>> DiG 9.3.4 <<>> @194.179.1.100 newpct.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 687
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;newpct.com. IN A

;; Query time: 50 msec
;; SERVER: 194.179.1.100#53(194.179.1.100)
;; WHEN: Tue Mar 27 18:16:33 2007
;; MSG SIZE rcvd: 28
[/code]

Mismo error. Aún no sabemos si Telefónica censura o qué está pasando. Veamos otros servidores, como los de OpenDNS:

[code]theefrit@teroknor:/tmp$ dig @208.67.222.222 newpct.com

; <<>> DiG 9.3.4 <<>> @208.67.222.222 newpct.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30966
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;newpct.com. IN A

;; ANSWER SECTION:
newpct.com. 1800 IN A 85.17.17.50

;; Query time: 220 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Tue Mar 27 18:18:39 2007
;; MSG SIZE rcvd: 44
[/code]

La opción @IP permite fijar un servidor de DNS distinto. NOERROR, esta ha ido bien. Vale, aparentemente no tira bien la cosa con los DNS de Telefónica. ¿Qué tienen en común estos sitios que fallan? Los WHOIS dan la clave:

[code]theefrit@teroknor:/tmp$ whois newpct.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: NEWPCT.COM
Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
[/code]
[code]theefrit@teroknor:/tmp$ whois gamestorrents.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: GAMESTORRENTS.COM
Registrar: ENOM, INC.
Whois Server: whois.enom.com
Referral URL: http://www.enom.com
Name Server: DNS1.NAME-SERVICES.COM
[/code]

Aquí vamos viendo que los dos dominios están en el mismo Registrar de DNS, ENOM, INC. Vamos a ver si Enom tira:

[code]theefrit@teroknor:/tmp$ dig @194.179.1.100 enom.com

; <<>> DiG 9.3.4 <<>> @194.179.1.100 enom.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6375
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;enom.com. IN A

;; Query time: 56 msec
;; SERVER: 194.179.1.100#53(194.179.1.100)
;; WHEN: Tue Mar 27 18:22:20 2007
;; MSG SIZE rcvd: 26
[/code]

También falla. Ups. Parece que algo no tira con los DNS de Telefónica y Enom. No creo que Telefónica se cargue así por las buenas ni aunque se lo pidan los reyes de la fritanga o el clan Bardem al unísono. Más bien va a ser una caída en el servicio. Llegados a este punto, las soluciones:

1. La sencilla y rápida: cambiar de DNS, los de OpenDNS nos pueden valer, tal como sugerían en el artículo original, 208.67.222.222 y 208.67.220.220. Cuando Telefónica resuelva la incidencia, podemos volver a los del ISP, que seguramente estarán menos cargados. Digo seguramente, nunca se sabe.
2. La del buen samaritano: llamar al servicio técnico y dar parte, armándote de paciencia para explicar al primer operador del 902 que no es un problema con tu Outlook ni tienes virus ni te interesa comprar una casa con ADSL. Luego puedes cambiar de DNS o echarle más paciencia hasta que se resuelva el asunto.

Y como conclusión, ¿hay que saber todo esto para determinar si Telefónica censura? La respuesta es NO. Lo que hay que hacer es no precipitarse, comprobar primero que no somos nosotros los que fallamos y llamar al servicio técnico. Si sabemos un poco de por dónde van los tiros, probar un DNS distinto y si no, nos tocará cagarnos un poquito en alguien, pero no llegar al extremo de lanzar a los cuatro vientos que Telefónica está censurando páginas de p2p. No adelantemos acontecimientos, por favor.

Sosiego y calma.

Actualización 20:56: a raíz del comentario de Nukeador, sobre si afecta a todos los dominios registrados en Enom, he estado indagando más. El problema exacto es un fallo de conectividad entre los DNS de NAME-SERVICES.COM y los de Telefónica. Sus servidores de nombres, nsX.name-services.com parecen estar caídos y no responden a ping ni a ninguna solicitud desde mi conexión, que sale al mundo vía Telefónica. Si al hacer el WHOIS del dominio registrado en Enom se obtiene que los servidores de nombres son de name-services.com, como pasa con los dominios perdidos, entonces no funcionará la resolución de nombres. En el caso de Nukeador, su dominio nukeador.com tiene otros servidores de nombres, accesibles desde la red de Telefónica y por tanto, la resolución del nombre funcionará.

El comando de linux dig permite además hacer trazas para ver hasta dónde llegas directamente desde tu equipo al resolver nombres:

[code]dig @SERVIDOR_NOMBRES nombre.tld +trace[/code]

Así, podemos ver:

[code]theefrit@teroknor:~$ dig @194.179.1.100 nukeador.com +trace

; <<>> DiG 9.3.4 <<>> @194.179.1.100 nukeador.com +trace
; (1 server found)
;; global options: printcmd
. 95296 IN NS a.root-servers.net.
. 95296 IN NS b.root-servers.net.
. 95296 IN NS c.root-servers.net.
. 95296 IN NS d.root-servers.net.
. 95296 IN NS e.root-servers.net.
. 95296 IN NS f.root-servers.net.
. 95296 IN NS g.root-servers.net.
. 95296 IN NS h.root-servers.net.
. 95296 IN NS i.root-servers.net.
. 95296 IN NS j.root-servers.net.
. 95296 IN NS k.root-servers.net.
. 95296 IN NS l.root-servers.net.
. 95296 IN NS m.root-servers.net.
;; Received 436 bytes from 194.179.1.100#53(194.179.1.100) in 657 ms

com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
;; Received 502 bytes from 198.41.0.4#53(a.root-servers.net) in 1070 ms

nukeador.com. 172800 IN NS ns1.dnspropio.com.
nukeador.com. 172800 IN NS ns2.dnspropio.com.
;; Received 108 bytes from 192.35.51.30#53(F.GTLD-SERVERS.NET) in 2673 ms

nukeador.com. 14400 IN A 195.140.142.122
nukeador.com. 14400 IN NS ns2.dnspropio.com.
nukeador.com. 14400 IN NS ns1.dnspropio.com.
;; Received 92 bytes from 195.140.142.122#53(ns1.dnspropio.com) in 1461 ms
[/code]

Mientras que si intentamos lo mismo con uno de los fallidos:

[code]theefrit@teroknor:~$ dig @194.179.1.100 newpct.com +trace

; <<>> DiG 9.3.4 <<>> @194.179.1.100 newpct.com +trace
; (1 server found)
;; global options: printcmd
. 95480 IN NS a.root-servers.net.
. 95480 IN NS b.root-servers.net.
. 95480 IN NS c.root-servers.net.
. 95480 IN NS d.root-servers.net.
. 95480 IN NS e.root-servers.net.
. 95480 IN NS f.root-servers.net.
. 95480 IN NS g.root-servers.net.
. 95480 IN NS h.root-servers.net.
. 95480 IN NS i.root-servers.net.
. 95480 IN NS j.root-servers.net.
. 95480 IN NS k.root-servers.net.
. 95480 IN NS l.root-servers.net.
. 95480 IN NS m.root-servers.net.
;; Received 436 bytes from 194.179.1.100#53(194.179.1.100) in 690 ms

com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
;; Received 500 bytes from 198.41.0.4#53(a.root-servers.net) in 794 ms

newpct.com. 172800 IN NS dns1.name-services.com.
newpct.com. 172800 IN NS dns2.name-services.com.
newpct.com. 172800 IN NS dns3.name-services.com.
newpct.com. 172800 IN NS dns4.name-services.com.
newpct.com. 172800 IN NS dns5.name-services.com.
;; Received 217 bytes from 192.33.14.30#53(B.GTLD-SERVERS.NET) in 2700 ms

;; reply from unexpected source: 127.0.0.1#53, expected 216.52.184.230#53
;; Warning: ID mismatch: expected ID 21051, got 53005
;; reply from unexpected source: 127.0.0.1#53, expected 63.251.92.193#53
;; Warning: ID mismatch: expected ID 21051, got 65011
;; reply from unexpected source: 127.0.0.1#53, expected 216.52.184.230#53
;; Warning: ID mismatch: expected ID 21051, got 53005
;; reply from unexpected source: 127.0.0.1#53, expected 63.251.92.193#53
;; Warning: ID mismatch: expected ID 21051, got 65011
;; reply from unexpected source: 127.0.0.1#53, expected 64.74.96.242#53
;; Warning: ID mismatch: expected ID 21051, got 26660
;; reply from unexpected source: 127.0.0.1#53, expected 64.74.96.242#53
;; Warning: ID mismatch: expected ID 21051, got 26660
;; connection timed out; no servers could be reached
[/code]

En este caso dig se va conectando a los servidores de nombres uno detrás de otro, en vez de dejar que el primero -194.179.1.100 en este caso- resuelva conectándose a quien considere oportuno. Como se puede ver, no hay forma de llegar a los servidores de nombres de name-services.com desde la red de Telefónica.

Hoy se me ha reiniciado de golpe y sin aviso el ordenador en el curro. Bueno sin aviso no. El LED del disco duro se puso a parpadear como un descosido. El caso es que tras la recuperación el bonito Windows Xp y su flamante sistema de informe de errores me mandó a una de las páginas de soporte de Microsoft. Realmente descriptiva. Sobre todo esa mezcla de traductor automático de la original en inglés.

La explicación del reinicio es bien sencilla,

Este mensaje ha aparecido porque un controlador de dispositivo instalado en el equipo provocó que el sistema operativo Windows se detuviese inesperadamente. Este tipo de error se conoce como “error de detención”. Ante un error de detención es necesario reiniciar el equipo.

Si no se quedó “detenido”, se reinició de forma unilateral. Bendito Eclipse que lo tenía todo guardado. No me hizo falta seguir con el “es necesario reiniciar el equipo…”

Me quedo con el segundo de los consejos que dan, asequible y bien sencillo de seguir:

Comentario: Debe agregar aquí el marcador de posición del fragmento 259

Clarito, ¿no?

O esa estupenda traducción de

Microsoft Update sitio web

¡Qué mensajes tan descriptivos de error!

El primero de ellos, un error del programa que gestiona la impresión de texto en el plástico de un envase. Exige un poco de agudeza visual, pero canta en seguida que algo no debería salir así:

Una bonita query o petición SQL al final de la lista de ingredientes, SELECT * FROM [Equipment Table] WHERE [Equipment Id] = 4. Visto en The Daily WTF.

Directamente desde Boing Boing, el segundo caso, esta vez, en una tarta. Al parecer el servicio de petición online de tartas no soportó que le pusieran caracteres raros al enviar el texto para la tarta y soltó una bonita excepción que acabó hecha caramelo por la impresora de tartas.

Me gustaría ver un cacharro de esos que imprimen comida…