Un fallo de 17 años

Esta vez se trata de un fallo en Windows, Windows plagued by 17-year-old privilege escalation bug. Concretamente afecta a la ‘Virtual DOS Machine’ introducida en 1993 con Windows NT. En Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack se pueden ver más detalles del fallo.

Es una cosa medio técnica y poco ‘glamourosa’ (creo), pero ¿por qué lo traigo aquí?
Me gusta recopilar este tipo de cosas, y ya habíamos hablado de fallos que permanecen mucho tiempo y que aparecen años después (en esta ocasión casi con la ‘mayoría de edad’) en El mito de los miles de ojos, hablando del software libre y este que traemos ahora es de software privativo, pero de difusión muy amplia.

La complejidad y la seguridad

En Symposium Summary: Complexity vs. Security—Choosing the Right Curve, Morning Keynote Address se puede leer un resumen cortito de la presentación del Dr. Ronald W. Ritchey en el Symposium de CERIAS (Center for for Education and Research in Information Assurance and Securigy) y en Symposium Transcript: Complexity vs. Security—Choosing the Right Curve, Morning Keynote Address una versión más completa. Lo que no encuentro es la presentación en sí, que creo que sería de utilidad.

Se habla del tema de si la complejidad del software hace que haya más fallos de seguridad o no. Hasta ahora, el sentimiento ‘común’ tenía que ver con lo que dijo Dan Geer, mostrando una relación directa entre el número de líneas de código y vulnerabilidades (por ejemplo, en el tutorial -cuidado, 346 páginas- Measuring Security (pdf), casi al final) y el autor no lo tiene tan claro, aludiendo a un par de estudios relacionados: Is Complexity Really the Enemy of Software Security (pdf) que parece ir en al línea de que no (aunque sólo se refiere a la máquina virtual de JavaScript de Mozilla) utilizando 9 medidas diferentes de complejidad y no encontrando relación. También el caso de Milk or Wine: Does Software Security Improve with Age? (pdf) (pdf), donde parece haber evidencias de que eso es así en el código de OpenBSD en el que las vulnerabilidades van decreciendo con el tiempo y sugieren que cuando alguien se concentra en hacer las cosas bien (pero … ¿quién hace eso?) uno puede conseguir código más complejo y no perder seguridad o incluso mejorarla. Además, probablemente la mayoría de los problemas están en el código ‘fundacional’, porque después en el mantenimiento hay menos ‘actividad’.

De todas formas, el número de líneas de código no sería la medida buena de la complejidad. Tal vez habría que concentrarse especialmente en los momentos en que se producen desarrollos más grandes (y cambios mayores) para evitar los problemas.

Sobre las opiniones de Dan Geer ya habíamos hablado en vidas pasadas, por ejemplo en Dan Geer sobre monocultura, diversidad, evolución y otros, con referencia a una conferencia sobre diversidad en la que también habla del tema de la complejidad un poquito.

¿Existen programas sin fallos de seguridad?

A mi me parece que es un poco tramposa la pregunta de ¿Existen programas sin fallos de seguridad? pero está bien que alguien la haga de vez en cuando para recordarnos donde estamos: 100% seguro no existe, o no tiene sentido o, seguramente, es demasiado caro para poder asumirlo. Los productos probados, incluso desarrollados pensando en la seguridad (como es el caso del djdns de Dan Berstein) a veces tienen problemas (por cosas que se sabían, o por circunstancias que podríamos llamar sobrevenidas). De hecho, como dice el artículo, este servidor de DNS no era vulnerable al problema que apareció con todos los demás servidores de este tipo el año pasado.

Análisis de ‘scanners’ de vulnerabilidades web

No soy un experto en el tema pero en Web Vulnerability Scanners Comparison se enlaza a un estudio donde se evalúan unas cuantos de estos productos de análisis de la seguridad de aplicaciones web con una aplicación vulnerable hecha a propósito. No salen demasiado bien paradas y, en todo caso, no es suficiente confiar en una herramienta de estas y pensar que estamos a salvo.