Microhistorias: Buffer Overflows. Trick or “Threat”?

• July 11, 2016
• tuxotron
• Seguridad, virus, Hacking, Programación, MicroHistoria

• Facebook
• Twitter
• Reddit
• LinkedIn

Entre mediados de los 90s y la primera década del siglo XXI, los ataques por desbordamiento de memoria ocuparon muchos titulares en la prensa técnica.

Un error de desbordamiento de memoria o más conocido como buffer overflow, aparece cuando un programa no gestiona correctamente la asignación de memoria (direccionamiento) en una operación de carga de datos a la memoria. Por lo tanto el programa está intentando almacenar una cantidad de datos en esa sección de la memoria (buffer) mayor de la que puede contener. Esto provoca un error en la ejecución del programa el cual puede corromper la información, detener la ejecución o en el peor de la casos, deja una puerta abierta a la ejecución de código malicioso. Es aquí donde aparece el ataque por desbordamiento de memoria. La técnica consiste básicamente en provocar el error buffer overflow para alterar la ejecución del programa y redireccionarlo a un fragmento de código diferente, tomando el control total del mismo.

Cuando buscamos información sobre buffer overflows o desbordamientos de memoria, el texto publicado en 1996 por Elias Levy, más conocido como Aleph One, en la famosa revista electrónica Phrack: Smashing The Stack For Fun And Profit, es un referente por no decir el referente en cuanto a la explotación de la pila se refiere.

Aunque éste es el texto más popular en la materia, un año antes, en 1995, concretamente éste data del 20 de octubre, otro hacker Peiter Zatko, más conocido como Mudge, había publicado, pero de forma privada, otro texto titulado How to write Buffer Overflows. Por lo tanto tiene sentido que en esa época se iniciara una avalancha de ataques de desbordamiento de memoria.

El aprovechamiento de este tipo de vulnerabilidad viene inluso de más atrás. De hecho el 2 de noviembre de 1988, el que se considera uno de los primeros gusanos de la historia, el famoso gusano de Morris, irrumpió en la prensa, no sólo por el impacto que causó, sino porque se convirtió en el primer caso convicto bajo la Ley de 1986 de Fraude y Abuso de Computadoras, Código de Estados Unidos.

Según palabras de su autor Robert Tappan Morris Jr, el gusano usaba cómo uno de los vectores de ataque un desbordamiento de memoria en el demonio fingerd, un servicio que actualmente prácticamente está extinto. El gusano realmente no fue creado con fines destructivos, pero gracias a un error en la lógica de infección, éste llegaba a infectar los servidores hasta siete veces, llegando a dejar estos inhabilitados, básicamente generando un ataque de denegación de servicio (DoS).

Robert T Morris Jr también cuenta que por aquella época, aunque la explotación de aplicaciones a través del desbordamiento de memoria no era algo común, sí que existía preocupación por la falta de comprobación de los límites de memoria por parte de los programadores. Esta falta de rigurosidad podría conducirnos a la ejecución arbitraria de código malicioso y por consiguiente a comprometer al sistema, como ocurrió en el caso de dicho gusano. Pero nos tenemos que remontar hasta octubre del año 1972, fecha datada del primer documento público conocido hasta la fecha, que trata este tema, creado por el Panel de Estudio de Planificación de Tecnología en Seguridad Informática (Computer Security Technology Planning Study Panel - PDF), a petición (bajo contrato) de las Fuerzas Aéreas de los Estados Unidos. En el apéndice I de dicho documento cuyo título es: Amenazas de seguridad y técnicas de penetración (Security Threats and penetration techniques), podemos ver un apartado titulado Verificación incompleta de parámetros (Incomplete Parameter Checking), en el que dice:

“Proporcionando a los programas de usuario una dirección fuera del espacio reservado, es posible hacer que el monitor devuelva datos no autorizados para ese usuario, o por lo menos, generar una serie de condiciones en la que el monitor cause un error de sistema. En un sistema operativo contemporáneo, una de las funciones proporcionadas es mover una cantidad limitada de información entre el espacio de sistema y el de usuario. El código encargado de ejecutar dicha operación no comprueba correctamente el origen y el destino de dicha información, permitiendo porciones del monitor ser sobrescritas por el usuario. Esto puede ser usado para inyectar código dentro del monitor y así el usuario tomar control del sistema”.

Por lo tanto este es la la primera documentación de ataques por desbordamiento de memoria que se conoce hasta la fecha.

Hasta ahora hemos visto de forma muy resumida algunos de los acontecimientos que han marcado un punto en la historia de los ataques por desbordamiento de memoria. Pero los desbordamientos de memoria no tienen por qué ser usados necesariamente como un vector de ataque. De hecho hay una anécdota en la que un juego llamado Ratchet & Clank: Up Your Arsenal de la empresa Insomniac Games, el cual se lanzó al mercado sin la funcionalidad de poder ser parcheado. Resulta que al principio del juego se mostraba al usuario la licencia del mismo. Esta licencia se descargaba de los servidores de la empresa. Esa parte concreta del código no comprobaba el tamaño del texto descargado por lo que era potencialmente vulnerable a una ataque de desbordamiento de memoria. Así que la propia compañía aprovechó dicho “vector de ataque” para mandar con la propia licencia el parche y midiendo estratégicamente el tamaño del mismo para que éste fuera ejecutado y así poder aplicar la actualización.

Otros errores famosos de desbordamiento de memoria aparecen en juegos clásicos como el Pac Man y la famosa pantalla partida, Galaga (pantalla de la muerte o arreglando Galaga), Donkey Kong o la familia Súper Mario, en los siguientes vídeos: https://www.youtube.com/watch?v=vAHXK2wut_I, https://www.youtube.com/watch?v=aqIYnFtDnRw , etc.

Los desbordamientos de memoria son un problema importante de seguridad, pero también hemos comprobado que algunas veces se pueden aprovechar para implementar “trucos” (tricks) no maliciosos o incluso obtener resultados divertidos como los errores en los juegos clásicos.

• MicroHistorias
• Juegos
• desbordamiento de memoria
• buffer overflows
• tricks
• threats