Bugs antiguos y moralejas

A veces coinciden en el tiempo sucesos de los que se puede sacar una especie de moraleja común y la serie reciente de errores con muchísimos años de historia me parece una de ellas. La grave vulnerabilidad en el protocolo DNS, que ha hecho actualizar a toda internet ha sido el ejemplo más claro, pero no el único y las tres historias son muy instructivas...

El primero, hace unos dos meses detectó un bug de 25 años en los BSD, en seekdir()[1] en el que, en algunos casos seekdir() no daba el resultado correcto. Como comentan en la propia historia, un bug muy difícil de encontrar y muy fácil de corregir.

El segundo es un bug con 33 años de antigüedad en yacc, encontrado por Otto Moerbeek[2], quien curiosamente también ha tenido un papel muy relevante en el descubrimiento del bug anterior.

El último es más peliagudo: problemas de diseño en el protocolo DNS permitían a un atacante hacer DNS cache poisoning de modo más efectivo que anteriores técnicas[3]. El descubridor de la vulnerabilidad, Dan Kaminsky, hace comentarios muy interesantes al respecto (las negritas son mías):

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that's no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got "lucky" here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don't have any information about. And so we are deploying this excellent design to provide no information.

Es muy curioso seguir los enlaces, porque la historia del parche es muy poco común y puede enseñar de la parte técnica y de la parte social del ecosistema internet.

Creo que la moraleja de todos ellos es clara, sobre todo leyendo las historias. Pero por recopilarlas (aún a riesgo de decir obviedades):

• El DNS o SMTP son protocolos pensados para una Internet que ya no existe: ninguno de ellos se diseñó pensando en la seguridad.
• Que lleve muchos años funcionando no significa que funcione en todas las circunstancias.
• Si se va a usar un software de un modo poco usual, aunque sea uno muy estable, conviene prepararse mentalmente para encontrar bugs.
• Los errores de diseño son más difíciles de arreglar (si es posible)
• Un buen diseño sobrepasa las expectativas del diseñador.
• Abierto no implica seguro, ni libre de fallos (Cerrado tampoco, claro[4])

[1]Un buen resumen en castellano, con interesantes conclusiones en El valle del viento helado "Un bug de 25 años en los BSD: seekdir()"
[2]Comentado en barrapunto en Corregido un error de hace 33 años en Yacc
[3]Comentado en barrapunto en Un agujero de seguridad en el protocolo DNS causa gran alarma
[4]Me ha llamado la atención el caso de un bug casi trivial en el en interop de .NET desde C++ nativo que lleva la menos seis años sin ser resuelto. No es el único caso ni el más grave ni la única empresa donde sucede eso, por supuesto. Sólo me ha parecido un ejemplo ilustrativo...

La misma entrada y más comentarios en Bugs antiguos y moralejas en barrapunto

Generación automática de exploits aprovechando los parches

La idea, hay que reconocerlo, es buenísima: crear automáticamente el programa que explotará la vulnerabilidad que trata de solucionar un parche mediante la información del mismo parche. La generación se realiza a través de la comparación entre el programa parcheado y el original. El artículo que desarrolla las posibles técnicas es Automatic Patch-Based Exploit Generation is Possible: Techniques and Implications. Parece que la cosa últimamente va de diferencias binarias :) (como en Actualizando el kernel Linux sin reiniciar )

Más comentarios en Bruce Schneier: Reverse-Engineering Exploits from Patches, programming reddit: Automatic Patch-Based Exploit Generation y LtU: Automatic Patch-Based Exploit Generation.

Actualización: Como Apunta Drizzt en las publicaciones de la gente de bindiff se examina más detenidamente el tema de la comparación binaria. En la misma entrada Drizzt también aporta algún enlace más al respecto.

La misma entrada y más comentarios en Generación automática de "exploits" aprovechando los parches en barrapunto

Actualizando el kernel Linux sin reiniciar

Leyendo el blog de Daniel Stenberg me entero de que ksplice ofrece la posibilidad de hacer actualizaciones de seguridad en el kernel Linux sin reiniciar, siempre y cuando los cambios no supongan modificaciones semánticas en los datos. Según el autor este tipo de modificaciones son aproximadamente un 80% del total de vulnerabilidades críticas. Es, aparentemente, el sueño de muchos administradores de sistemas...

Más información en el artículo de presentación, Ksplice: An automatic system for rebootless Linux kernel security updates (pdf), en la lista del kernel, A system for rebootless kernel security updates y en programming.reddit.

Actualizando el kernel Linux sin reiniciar en barrapunto

La aritmética de punteros, su desbordamiento y la seguridad

Me he enterado vía el valle del viento helado de una nueva polémica acerca de gcc y su implementación. El hecho es que gcc cambió su comportamiento en cuanto a comparaciones entre punteros incrementados y ha provocado muchos meses después una alerta de seguridad desproporcionada y según los desarrolladores de gcc, falsa (Se puede oír desde aquí el ruido y la furia)

El caso es que, entrando en profundidad, es una optimización casi "trivial" que hace que p + C1 < p + C2 pase a ser C1 < C2 sin tener en cuenta el posible desbordamiento (overflow) de ambas operaciones. Hay que decir además que el estándar (de C y de C++) declara no definido el valor del resultado de la suma entre un puntero y un entero cuando se sobrepasa el tamaño del objeto al que apunta.

Es muy importante este último punto, porque deja traslucir un error de concepto: la comprobación de overflow propuesta en la alerta(*) es muy burda porque sólo se comprueba el desbordamiento de la operación aritmética, no que nos estamos saliendo del rango permitido. Sin embargo lo que deben saber el programador y el programa a la vez, cuando están manejando aritmética de punteros es cual es el desplazamiento (offset) máximo, de cuanta memoria se dispone. Si eso no lo sabe, es inútil cualquier otra comprobación...

Hay que hacer notar además que la optimización de la que se habla aquí la aplican casi todos los compiladores y lo que provoca la alerta es en realidad el cambio de comportamiento, no que sea incorrecto.

También recuerda esto que es muy mala política basar el código en detalles de implementación específicos de la plataforma. En este caso y en muchos otros, los desarrolladores de gcc tiran de cita del estándar para argumentar sus decisiones. Los usuarios se quejan, llamándoles abogados del lenguaje (language lawyer) pero en momentos como esos hay que recordar que probablemente están defendiendo sus decisiones de implementación y lo importante de esas decisiones para el éxito de una tecnología.

(*)char *buf;
int len;
len = 1 << 30;
if (buf+len < buf){ Overflow }

La aritmética de punteros, su desbordamiento y la seguridad en barrapunto