Para que se vea comprometida la seguridad de un sistema algún agente debe usar sus privilegios en forma no autorizada. El caso más frecuente es el en el que algún programa es engañado para que efectúe acciones no autorizadas.
Ejemplos típicos de ésto han sido los virus que se han distribuido por correo, aprovechando las facilidades de ciertos sistemas de correo para ejecutar automáticamente código que viene en mensajes, y los similares con aplicaciones de oficina. Éstos caen más bien en el ámbito de diseño básicamente mal hecho, que debiera rehacerse. Claro que el costo de tal cambio es inmenso.
La otra gran fuente de problemas han sido errores de programación (un buen resumen es Secure Programs HOWTO , que incluye discusión de las últimas clasees de vulnerabilidades descubiertas, y Secure UNIX Programming FAQ , que incluye referencias a una gran cantidad de FAQs adicionales). La pregunta obvia entonces es la relación entre calidad de software (ausencia de fallas) con su vulnerabilidad frente a ataques externos.
Como ya dijo Dijkstra: " Pruebas de software pueden demostrar la precencia de errores, no su ausencia " simples pruebas nunca permitirán lograr software seguro. El problema es que los atacantes buscan activamente provocar situaciones extremas (que nunca ocurrirían bajo uso normal) precisamente con la intención de aprovechar errores en situaciones pasadas por alto en el diseño, la programación, y las pruebas. Las técnicas a emplear entonces para asegurar programas y sistemas son de auditoría más que pruebas en el sentido tradicional. Herramientas al efecto incluyen ITS4 , aunque se pueden usar también con buenos resultados opciones de los compiladores para obtener más mensajes de advertencia, y el uso de bibliotecas especiales de verificación. Sin embargo, la herramienta principal sigue siendo la persona que revisa el código. En este sentido, los sistemas de fuentes abiertas tienen una ventaja, dado que hay más posibles auditores. Por el otro lado, los fuentes pueden ser también revisados por los malandrines. En todo caso, esto no es tanta desventaja como parece a primera vista, muchas de las vulnerabilidades se pueden encontrar simplemente tomando los programas ejecutables y sometiéndolos a entradas absurdas (nombres de archivo inmensamente largos, o que incluyen caracteres de control, etc).
Por ejemplo, al enterarme del tipo de problemas de seguridad que podría introducir el rebalsar arreglos en programas que corren con mayor privilegio, y teniendo a mano la en ese entonces última versión del programa de conexión vía telefónica dip revisé el uso de strings y arreglos en éste. Descubrí varios usos dudosos, los corregí y envié un parche al encargado, quien lo integró a la versión oficial. Poco depués se descubrieron problemas de seguridad en este paquete, que mis parches resolvían. No habría sabido cómo construir un ataque usando los problemas encontrados, y tampoco sé (ni me interesa particularmente saber) cuál de los errores llevaba al problema de seguridad.
Un punto de interés es que el tipo de errores de programación que se reflejan en problemas de seguridad más comunes suelen dan lugar a caídas de los programas ante pruebas con datos al azar, como en Fuzz (hay una versión actualizada de la herramienta del caso en Source Forge ). En el año 1990, se probaron entre 49 y 85 utilitarios de cada uno de 5 sistemas Unix comerciales, con el resultado de 25 a 33% de fallas. Las pruebas se repitieron en 1995 en 9 sistemas, incluyendo una distribución de Linux y los utilitarios de GNU. Se probaron entre 47 y 80 programas en cada ambiente, con tasas de fallas entre 15 y 43% en los Unix comerciales. Esto se compara con un 9% para Linux y un 6% para GNU. Lo preocupante es que en los casos donde se pudieron determinar los errores en versiones del mismo sistema en 1990 y 1995, muchos de los errores originales seguían en el código, a pesar de estar ampliamente disponibles los resultados y las herramientas usadas. Eso si, estos resultados son a lo más indicativos de la calidad general del software de cada sistema, no indica necesariamente el nivel de seguridad de otro software que se distribuye con él. Las pruebas de 1995 no hicieron mella en los programas servidores probados.
Para completar el cuadro, a principios del 2000 se repitió este tipo de pruebas sobre Windows NT. La tasa de fallas fue de 100%.