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