Aprendiendo de los errores (II)

Dan J. Berstein reconoció una vulnerabilidad en djbdns y la recompensó con mil dólares y por supuesto no se han hecho esperar reflexiones acerca de la seguridad informática, su (im)posibilidad y su relación con lo disponible del código.

Entonces leo con interés, vía el nuevo subarrapunto de fernand0, un comentario en hispasec que no por evidente debe dejar de repetirse: no existe software sin fallos de seguridad, pero los que menos tienen son aquellos que han sido diseñados y programados desde su inicio con la seguridad y la simplicidad como guía.

Y ello descarta a casi todo el software y probablemente más al comercial, que tiene más presiones para añadir más y más cosas. Recordemos, que como decía Alan J. Perlis A la larga cualquier programa se vuelve rococó. Después escombros. Lo de siempre, funcionalidad contra robustez y simplicidad :)

De todos modos el caso de djbdns es también interesante por el tipo de fallo encontrado. En Hacker News comentaban que el problema era en la implementación de la compresión que usa en el protocolo DNS para sus paquetes, para eliminar redundancias. Y precisamente Bernstein había hablado negativamente del método de compresión (descrito, claro, en el RFC 1035, 4.1.4, página 30) Extractando de la crítica de Bernstein:

Un problema con la compresión DNS es la cantidad de código necesario para analizarla. Localizar de modo fiable los nombres lleva un trabajo que habría sido evitable para una caché DNS. La compresión LZ77 habría sido mucho más fácil de implementar.

Otro problema con la compresión DNS es la cantidad de código necesario para generarlo correctamente. [...]

Otro problema con la compresión DNS es que no es particularmente efectiva. LZ77 habría funcionado mejor en esos tipos de datos y funcionaría mejor con los tipos de registros que se popularizarían en el futuro [...](Y aquí habla de incompatibilidades de algunas versiones de BIND con el RFC)

Muy interesante todo el texto original, incluidas las elipsis ;) anque bastante específicas del caso DNS. Lo que no me ha quedado claro es la razón de no usar LZ77, si fue un caso de Síndrome NIH, de hackerismo o tenía algo que ver con las patentes sobre estos tipos de compresión que llevaban haciéndose desde 1984 como la del LZ78. Pero vamos como regla general parece mucho mejor usar un algoritmo conocido que inventar uno nuevo, a no ser que trabajes en eso, en innovar...

Creo que la moraleja es clara, como se dice a veces exagerando el mejor código es el que no existe sobre todo desde el punto de vista de la reducción de bugs y aún más si se trata de seguridad.

(Esto se llama Aprendiendo de los errores (II) porque ya escribí en su día Bugs antiguos y moralejas , que iba sobre lo mismo, también salía DJB y el DNS, en aquel caso con el bug/error de diseño que explotó Kaminsky)


La misma entrada y más comentarios en Aprendiendo de los errores (II) en barrapunto

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