Grandes respuestas hasta ahora por Phillip Remaker y William Emmanuel Yu.
Pongamos un poco de color en esto.
En un documento de 1972 (aquí -> http://csrc.nist.gov/publication…), el comité de Estudio de Planificación de Tecnología de Seguridad Informática informó que, en teoría, podría sobrepasar los datos en un programa e inyectar código en la secuencia de ejecución . Era completamente oscuro excepto en círculos delgados, casi nadie hablaba de eso en absoluto. Las buenas prácticas de codificación consistían en verificar para asegurarse de que no tomara una entrada más grande que el espacio que tenía para almacenarla, pero nadie habló de por qué . (esta fue la razón, por cierto)
- ¿Cómo podría crear un sitio web totalmente seguro protegido con contraseña?
- ¿Cómo se nombra una vulnerabilidad de seguridad después de ser descubierta?
- ¿Qué es el programa 'ZipCloud' y por qué se abre cuando enciendo mi Mac? ¿Es seguro o un virus?
- ¿Qué debe incluir la política de seguridad empresarial para garantizar la protección contra fugas de datos, amenazas de virus / malware / hacks y otras amenazas?
- Cómo eliminar el malware / adware 'Express Find' de mi computadora
Luego, en 1989, el gusano Morris utilizó el desbordamiento del búfer en el comando de dedo de UNIX como parte de cómo se propagó. Si había desarmado el gusano, lo sabía, pero era completamente desconocido para la gran mayoría de los programadores (e incluso los profesionales de seguridad). Aun así, nadie sabía realmente qué hacer con eso.
Un avance rápido hasta 1996 cuando, en Phrack # 49, Elias Levy publicó Smashing The Stack for Fun and Profit.
Es una buena explicación de nivel medio de cómo se puede codificar para sobrescribir la pila en C, basada en la forma en que ocurrió la asignación de memoria en casi todas las versiones del tiempo de ejecución implementadas hasta la fecha. Además de la teoría, hay un código de ejemplo que muestra que sí, esto realmente funciona.
Todavía. Todo papel, sin código.
No fue hasta que apareció el Código Rojo en 2001 que la mayoría de la gente prestó atención.
La teoría se había convertido en práctica, y si estaba ejecutando el IIS de Microsoft, podría verse comprometido instantáneamente.
Entonces, tenemos un vector de ataque teórico inicial descrito en 1972: que si puede anular la memoria asignada para datos, puede inyectar código ejecutable para subvertir el programa original. Luego tenemos a alguien que realmente hizo eso (probablemente Robert Morris Sr. tenía el documento original por ahí y Robert Morris Jr. sabía de la técnica) casi dos décadas después, y luego otra década más tarde alguien da una reseña con diapositivas y gráficos y código de ejemplo, y aún faltan otros cinco años para que aparezca en la naturaleza.
Esa es la diferencia entre un ataque “teórico” y un ataque real.
Para mí, es fácil ver ataques teóricos. Puedo mirar el código y la infraestructura, y pensar “bueno, si quisiera romper esto, comenzaría aquí … ” y tarde o temprano, encontraría algo que, en teoría, funcionaría. A veces es instantáneamente obvio. A veces, toma un poco de empuje.
Pero la cuestión es que, una vez que veo que PUEDE hacerse, es bastante fácil ver otras cosas que también podrían hacerse, y encontrar formas de evitar que eso suceda.
¿Encontrar un ataque práctico? Más fuerte. Mucho, mucho más difícil. Mucha suerte involucrada.
