martes, 2 de agosto de 2016

Buffer Overflows. Trick or “Threat”?


JumpToEsp.png
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”.
Nota: “monitor” hace referencia al núcleo (kernel) 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_Ihttps://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.

Fuente: CyberHades

jueves, 15 de mayo de 2014

domingo, 13 de octubre de 2013

Revistas clásicas de Informática escaneadas

REvistasClasicas

En AtariMagazineArchive puedes encontrar una colección realmente impresionante de revistas escaneadas de la época dorada de los ordenadores de 8 bits. Desde la mítica Compute! hasta otra realmente clásicas llamada ROM

No podía faltar la revista española del Spectrum por excelencia, MicroHobby. Desde este enlace puedes descargar al completo todas las revistas.

Otro enlace que tiene material interesante, como revistas Byte de los 70 escaneadas es VintageComputer.net

Si quieres prácticamente todas las revistas sobre el Spectrum, no olvides visitar este enlace de la web de World Of Spectrum.

Seguiremos publicando nuevos enlaces.

viernes, 11 de octubre de 2013

Proceso de carga de Basic de 4k en un Altair 8800


Una de mis historias favoritas y sin duda alguna de las más trascendentales en la historia de la informática personal, es la que titulamos como: Altair, hackers de garaje y la revolución de Silicon Valley.

En ella, nuestro protagonista es al Altair 8800. Éste fue entre otros, jugó un papel determinante en la creación de Micro-Soft, tras la creación del Altair Basic.

Si alguna vez te has preguntado como se cargaban los programas en Altair, recuerda que éste no tenía teclado o ningún tipo de rutina de carga en ninguno de sus chips. Todo el trabajo recaía sobre el usuario u operador de la máquina, en la que tenía introducir las rutinas de carga de memoria y demás a base de conmutadores de forma binaria.

Aquí lo que os voy a dejar es un vídeo de demostración de como se llevaba a cabo dicho proyecto. Además en el mismo, podemos ver la carga del Basic 4K, pero usando un teletipo.




El Altair 8800 que aparece en el vídeo es una réplica del mismo usando hardware moderno. Si estás interesado en montar el tuyo propio o incluso comprar uno ya montado, puedes conseguirlo a través de http://altairclone.com/.