Ya tiene unos días (y solución) pero quede aquí a título de inventario: Researchers attack my iPhone via SMS: mediante el envío de un mensaje especial el teléfono queda a merced del atacante (mediante más mensajes de control). Lo vi en Vulnerabilidad en los iPhone vía SMS.
Ya habíamos hablado de ataques a teléfonos de la marca Nokia en ‘Regalos’ navideños de seguridad y también a routers, Cross Site Scripting por SMS.
En State of the Art Post Exploitation in Hardened PHP Environments se habla del trabajo de Stefan Esser sobre fallos de seguridad y ataques realizados en instalaciones de PHP previamente fortalecidas. Es bastante técnico (al menos para mi) pero me pareció interesante la primera parte, donde hace un repaso de las medidas de protección disponibles en el lenguaje actualmente (y sus defectos y debilidades).
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.
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.
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.
