En seguridad de la información y programación , un desbordamiento del búfer , o desbordamiento del búfer , es una anomalía en la que un programa , mientras escribe datos en un búfer , sobrepasa el límite del búfer y sobrescribe las ubicaciones de memoria adyacentes .
Los búferes son áreas de memoria reservadas para almacenar datos, a menudo mientras se mueven de una sección de un programa a otra, o entre programas. Los desbordamientos de búfer a menudo pueden ser provocados por entradas mal formadas; si se supone que todas las entradas serán más pequeñas que un cierto tamaño y el búfer se crea para que tenga ese tamaño, entonces una transacción anómala que produzca más datos podría hacer que se escriban más allá del final del búfer. Si esto sobrescribe los datos adyacentes o el código ejecutable, esto puede resultar en un comportamiento errático del programa, incluidos errores de acceso a la memoria, resultados incorrectos y bloqueos .
Aprovechar el comportamiento de un desbordamiento de búfer es un exploit de seguridad bien conocido . En muchos sistemas, el diseño de la memoria de un programa, o del sistema en su conjunto, está bien definido. Al enviar datos diseñados para causar un desbordamiento del búfer, es posible escribir en áreas que se sabe que contienen código ejecutable y reemplazarlo con código malicioso , o sobrescribir selectivamente datos pertenecientes al estado del programa, lo que provoca un comportamiento no previsto por el programador original. Los búferes están muy extendidos en el código del sistema operativo (SO), por lo que es posible realizar ataques que realicen escalada de privilegios y obtengan acceso ilimitado a los recursos de la computadora. El famoso gusano Morris en 1988 utilizó esto como una de sus técnicas de ataque.
Los lenguajes de programación comúnmente asociados con los desbordamientos de búfer incluyen C y C ++ , que no brindan protección incorporada contra el acceso o la sobrescritura de datos en cualquier parte de la memoria y no verifican automáticamente que los datos escritos en una matriz (el tipo de búfer integrado) estén dentro de los límites de esa matriz. La comprobación de límites puede evitar desbordamientos del búfer, pero requiere código y tiempo de procesamiento adicionales. Los sistemas operativos modernos utilizan una variedad de técnicas para combatir los desbordamientos de búfer maliciosos, en particular aleatorizando el diseño de la memoria o dejando deliberadamente espacio entre los búferes y buscando acciones que escriban en esas áreas ("canarios").
Descripción técnica
Se produce un desbordamiento del búfer cuando los datos escritos en un búfer también corrompen los valores de los datos en las direcciones de memoria adyacentes al búfer de destino debido a una comprobación de límites insuficiente . Esto puede ocurrir al copiar datos de un búfer a otro sin verificar primero que los datos se ajustan al búfer de destino.
Ejemplo
En el siguiente ejemplo expresado en C , un programa tiene dos variables que son adyacentes en la memoria: un búfer de cadena de 8 bytes de longitud, A, y un entero big-endian de dos bytes , B.
char A [ 8 ] = "" ; corto sin firmar B = 1979 ;
Inicialmente, A no contiene nada más que cero bytes y B contiene el número 1979.
nombre de la variable | A | B | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
valor | [ cadena nula ] | 1979 | ||||||||
valor hexadecimal | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 07 | BB |
Ahora, el programa intenta almacenar la cadena terminada en nulo "excessive"
con codificación ASCII en el búfer A.
strcpy ( A , "excesivo" );
"excessive"
tiene 9 caracteres y se codifica en 10 bytes, incluido el terminador nulo, pero A solo puede ocupar 8 bytes. Al no verificar la longitud de la cadena, también sobrescribe el valor de B:
nombre de la variable | A | B | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
valor | 'e' | 'x' | 'c' | 'e' | 's' | 's' | 'i' | 'v' | 25856 | |
maleficio | 65 | 78 | 63 | 65 | 73 | 73 | 69 | 76 | 65 | 00 |
El valor de B ahora ha sido reemplazado inadvertidamente por un número formado a partir de parte de la cadena de caracteres. En este ejemplo, "e" seguida de un byte cero se convertiría en 25856.
La escritura de datos más allá del final de la memoria asignada a veces puede ser detectada por el sistema operativo para generar un error de falla de segmentación que termina el proceso.
Para evitar que se produzca el desbordamiento del búfer en este ejemplo, la llamada a strcpypodría reemplazarse con strlcpy, que toma la capacidad máxima de A (incluido un carácter de terminación nula) como parámetro adicional y garantiza que no se escriba más de esta cantidad de datos. a A:
strlcpy ( A , "excesivo" , tamaño de ( A ));
Cuando está disponible, strlcpyse prefiere la función de biblioteca sobre la strncpyque no termina en nulo el búfer de destino si la longitud de la cadena de origen es mayor o igual que el tamaño del búfer (el tercer argumento pasado a la función), por Alo tanto , no puede ser nulo. terminado y no puede tratarse como una cadena de estilo C válida.
Explotación
Las técnicas para aprovechar una vulnerabilidad de desbordamiento del búfer varían según la arquitectura , el sistema operativo y la región de memoria. Por ejemplo, la explotación en el montón (utilizada para la memoria asignada dinámicamente) difiere notablemente de la explotación en la pila de llamadas .
Explotación basada en pilas
Un usuario con inclinaciones técnicas puede aprovechar los desbordamientos de búfer basados en pilas para manipular el programa en su beneficio de una de varias formas:
- Sobrescribiendo una variable local que se encuentra cerca del búfer vulnerable en la pila, para cambiar el comportamiento del programa.
- Sobrescribiendo la dirección de retorno en un marco de pila para apuntar al código seleccionado por el atacante, generalmente llamado shellcode . Una vez que la función regresa, la ejecución se reanudará en el shellcode del atacante.
- Al sobrescribir un puntero de función [1] o un manejador de excepciones para apuntar al código de shell, que posteriormente se ejecuta
- Sobrescribiendo una variable local (o puntero) de un marco de pila diferente, que será utilizado por la función que posee ese marco más adelante. [2]
El atacante diseña datos para provocar una de estas vulnerabilidades y luego coloca estos datos en un búfer proporcionado a los usuarios por el código vulnerable. Si la dirección de los datos proporcionados por el usuario que se utilizan para afectar el desbordamiento del búfer de pila es impredecible, aprovechar un desbordamiento del búfer de pila para provocar la ejecución remota de código se vuelve mucho más difícil. Una técnica que se puede utilizar para aprovechar tal desbordamiento de búfer se llama " trampolín ". En esa técnica, un atacante encontrará un puntero al búfer de pila vulnerable y calculará la ubicación de su código de shell en relación con ese puntero. Luego, usarán la sobreescritura para saltar a una instrucción que ya está en la memoria que hará un segundo salto, esta vez en relación con el puntero; ese segundo salto ramificará la ejecución en el shellcode. Las instrucciones adecuadas suelen estar presentes en código grande. El Proyecto Metasploit , por ejemplo, mantiene una base de datos de códigos de operación adecuados, aunque solo enumera los que se encuentran en el sistema operativo Windows . [3]
Explotación basada en montón
Un desbordamiento de búfer que se produce en el área de datos de pila se denomina desbordamiento de pila y se puede explotar de una manera diferente a la de los desbordamientos basados en pila. La aplicación asigna dinámicamente la memoria en el montón en tiempo de ejecución y, por lo general, contiene datos del programa. La explotación se realiza corrompiendo estos datos de formas específicas para hacer que la aplicación sobrescriba las estructuras internas, como los punteros de listas vinculadas. La técnica de desbordamiento de pila canónica sobrescribe el enlace de asignación de memoria dinámica (como metadatos malloc ) y usa el intercambio de puntero resultante para sobrescribir un puntero de función de programa.
La vulnerabilidad GDI + de Microsoft en el manejo de archivos JPEG es un ejemplo del peligro que puede presentar un desbordamiento de pila. [4]
Barreras a la explotación
La manipulación del búfer, que se produce antes de que se lea o ejecute, puede provocar el fracaso de un intento de explotación. Estas manipulaciones pueden mitigar la amenaza de explotación, pero pueden no hacerla imposible. Las manipulaciones podrían incluir conversión a mayúsculas o minúsculas, eliminación de metacaracteres y filtrado de cadenas no alfanuméricas . Sin embargo, existen técnicas para evitar estos filtros y manipulaciones; código alfanumérico , código polimórfico , código mutante y ataques de retorno al libc . Se pueden utilizar los mismos métodos para evitar la detección mediante sistemas de detección de intrusos . En algunos casos, incluso cuando el código se convierte a Unicode , [5] los divulgadores han tergiversado la amenaza de la vulnerabilidad como sólo denegación de servicio cuando en realidad es posible la ejecución remota de código arbitrario.
Practicidades de la explotación
En los exploits del mundo real, hay una variedad de desafíos que deben superarse para que los exploits funcionen de manera confiable. Estos factores incluyen bytes nulos en direcciones, variabilidad en la ubicación de shellcode, diferencias entre entornos y varias contramedidas en funcionamiento.
Técnica de trineo NOP
Un trineo NOP es la técnica más antigua y más conocida para aprovechar los desbordamientos del búfer de pila. [6] Resuelve el problema de encontrar la dirección exacta del búfer aumentando efectivamente el tamaño del área objetivo. Para hacer esto, secciones mucho más grandes de la pila se corrompen con la instrucción de máquina no operativa . Al final de los datos proporcionados por el atacante, después de las instrucciones de no operación, el atacante coloca una instrucción para realizar un salto relativo a la parte superior del búfer donde se encuentra el código de shell . Esta colección de no-ops se conoce como el "NOP-sled" porque si la dirección de retorno se sobrescribe con cualquier dirección dentro de la región no-op del búfer, la ejecución se "deslizará" hacia abajo por las no-ops hasta que sea redirigido al código malicioso real por el salto al final. Esta técnica requiere que el atacante adivine en qué parte de la pila se encuentra el trineo NOP en lugar del código de shell comparativamente pequeño. [7]
Debido a la popularidad de esta técnica, muchos proveedores de sistemas de prevención de intrusiones buscarán este patrón de instrucciones de máquina no operativa en un intento de detectar shellcode en uso. Es importante tener en cuenta que un trineo NOP no necesariamente contiene solo las instrucciones tradicionales de la máquina no operativa; cualquier instrucción que no corrompa el estado de la máquina hasta un punto en el que el código de shell no se ejecute puede usarse en lugar de la no operación asistida por hardware. Como resultado, se ha convertido en una práctica común para los escritores de exploits componer el trineo sin operaciones con instrucciones elegidas al azar que no tendrán un efecto real en la ejecución del código de shell. [8]
Si bien este método mejora en gran medida las posibilidades de que un ataque tenga éxito, no está exento de problemas. Los exploits que utilizan esta técnica aún deben confiar en cierta cantidad de suerte para adivinar las compensaciones en la pila que se encuentran dentro de la región del trineo NOP. [9] Una suposición incorrecta generalmente resultará en el bloqueo del programa de destino y podría alertar al administrador del sistema sobre las actividades del atacante. Otro problema es que el trineo NOP requiere una cantidad mucho mayor de memoria para guardar un trineo NOP lo suficientemente grande como para ser de alguna utilidad. Esto puede ser un problema cuando el tamaño asignado del búfer afectado es demasiado pequeño y la profundidad actual de la pila es poco profunda (es decir, no hay mucho espacio desde el final del marco de la pila actual hasta el inicio de la pila). A pesar de sus problemas, el trineo NOP es a menudo el único método que funcionará para una plataforma, entorno o situación determinados y, como tal, sigue siendo una técnica importante.
El salto a la dirección almacenada en una técnica de registro.
La técnica de "saltar para registrar" permite una explotación confiable de los desbordamientos del búfer de pila sin la necesidad de espacio adicional para un trineo NOP y sin tener que adivinar las compensaciones de pila. La estrategia es sobrescribir el puntero de retorno con algo que hará que el programa salte a un puntero conocido almacenado dentro de un registro que apunta al búfer controlado y, por lo tanto, al código de shell. Por ejemplo, si el registro A contiene un puntero al inicio de un búfer, entonces cualquier salto o llamada que tome ese registro como operando puede usarse para obtener el control del flujo de ejecución. [10]
En la práctica, es posible que un programa no contenga intencionalmente instrucciones para saltar a un registro en particular. La solución tradicional es encontrar una instancia no intencionada de un código de operación adecuado en una ubicación fija en algún lugar de la memoria del programa. En la figura E de la izquierda hay un ejemplo de una instancia no intencionada de la jmp esp
instrucción i386 . El código de operación de esta instrucción es FF E4
. [11] Esta secuencia de dos bytes se puede encontrar en un desplazamiento de un byte desde el inicio de la instrucción call DbgPrint
en la dirección 0x7C941EED
. Si un atacante sobrescribe la dirección de retorno del programa con esta dirección, el programa primero saltará 0x7C941EED
, interpretará el código de operación FF E4
como la jmp esp
instrucción y luego saltará a la parte superior de la pila y ejecutará el código del atacante. [12]
Cuando esta técnica es posible, la gravedad de la vulnerabilidad aumenta considerablemente. Esto se debe a que la explotación funcionará con la suficiente fiabilidad como para automatizar un ataque con una garantía virtual de éxito cuando se ejecute. Por esta razón, esta es la técnica más comúnmente utilizada en los gusanos de Internet que aprovechan las vulnerabilidades de desbordamiento del búfer de pila. [13]
Este método también permite colocar el código de shell después de la dirección de retorno sobrescrita en la plataforma Windows. Dado que los ejecutables se basan principalmente en la dirección 0x00400000
y x86 es una arquitectura Little Endian , el último byte de la dirección de retorno debe ser nulo, lo que termina la copia del búfer y no se escribe nada más allá de eso. Esto limita el tamaño del código de shell al tamaño del búfer, que puede ser demasiado restrictivo. Las DLL están ubicadas en la memoria alta (arriba 0x01000000
) y, por lo tanto, tienen direcciones que no contienen bytes nulos, por lo que este método puede eliminar bytes nulos (u otros caracteres no permitidos) de la dirección de retorno sobrescrita. Usado de esta manera, el método a menudo se denomina "trampolín DLL".
Contramedidas protectoras
Se han utilizado varias técnicas para detectar o prevenir desbordamientos de búfer, con varias compensaciones. La forma más confiable de evitar o prevenir los desbordamientos del búfer es utilizar la protección automática a nivel de idioma. Sin embargo, este tipo de protección no se puede aplicar al código heredado y, a menudo, las limitaciones técnicas, comerciales o culturales exigen un lenguaje vulnerable. Las siguientes secciones describen las opciones e implementaciones disponibles.
Elección del lenguaje de programación
Ensamblador y C / C ++ son lenguajes de programación populares que son vulnerables al desbordamiento del búfer, en parte porque permiten el acceso directo a la memoria y no están fuertemente tipados . [14] C no proporciona protección incorporada contra el acceso o la sobrescritura de datos en cualquier parte de la memoria; más específicamente, no verifica que los datos escritos en un búfer estén dentro de los límites de ese búfer. Las bibliotecas estándar de C ++ proporcionan muchas formas de almacenar datos en búfer de forma segura, y la biblioteca de plantillas estándar (STL) de C ++ proporciona contenedores que, opcionalmente, pueden realizar la comprobación de límites si el programador llama explícitamente a las comprobaciones mientras accede a los datos. Por ejemplo, vector
la función miembro de a at()
realiza una verificación de límites y lanza una out_of_range
excepción si falla la verificación de límites. [15] Sin embargo, C ++ se comporta como C si la verificación de límites no se llama explícitamente. También existen técnicas para evitar desbordamientos de búfer para C.
Los lenguajes fuertemente tipados y que no permiten el acceso directo a la memoria, como COBOL, Java, Python y otros, evitan que se produzca un desbordamiento del búfer en la mayoría de los casos. [14] Muchos lenguajes de programación distintos de C / C ++ proporcionan verificación en tiempo de ejecución y, en algunos casos, incluso verificación en tiempo de compilación, lo que podría enviar una advertencia o generar una excepción cuando C o C ++ sobrescribiría datos y continuaría ejecutando instrucciones adicionales hasta que se obtengan resultados erróneos. lo que puede hacer que el programa se bloquee o no. Ejemplos de tales lenguajes incluyen Ada , Eiffel , Lisp , Modula-2 , Smalltalk , OCaml y tales C-derivados como Cyclone , Rust y D . Los entornos de código de bytes de Java y .NET Framework también requieren la verificación de límites en todas las matrices. Casi todos los lenguajes interpretados protegerán contra desbordamientos de búfer, lo que indica una condición de error bien definida. A menudo, cuando un idioma proporciona suficiente información de tipo para establecer límites, se proporciona una opción para habilitarla o deshabilitarla. El análisis de código estático puede eliminar muchas comprobaciones dinámicas de tipo y límite, pero las implementaciones deficientes y los casos incómodos pueden disminuir significativamente el rendimiento. Los ingenieros de software deben considerar cuidadosamente las compensaciones entre la seguridad y los costos de rendimiento al decidir qué idioma y configuración del compilador utilizar.
Uso de bibliotecas seguras
El problema de los desbordamientos de búfer es común en los lenguajes C y C ++ porque exponen detalles de representación de bajo nivel de búferes como contenedores para tipos de datos. Por lo tanto, los desbordamientos del búfer deben evitarse manteniendo un alto grado de corrección en el código que realiza la gestión del búfer. También se ha recomendado durante mucho tiempo evitar las funciones de biblioteca estándar que no tienen límites comprobados, como gets
, scanf
y strcpy
. El gusano Morris aprovechó una gets
llamada en finger . [dieciséis]
Las bibliotecas de tipos de datos abstractos bien escritas y probadas que centralizan y realizan automáticamente la administración del búfer, incluida la verificación de límites, pueden reducir la ocurrencia y el impacto de los desbordamientos del búfer. Los dos tipos de datos de bloques de construcción principales en estos lenguajes en los que suelen producirse desbordamientos de búfer son cadenas y matrices; por lo tanto, las bibliotecas que evitan los desbordamientos del búfer en estos tipos de datos pueden proporcionar la gran mayoría de la cobertura necesaria. Aún así, no utilizar correctamente estas bibliotecas seguras puede provocar desbordamientos de búfer y otras vulnerabilidades; y, naturalmente, cualquier error en la propia biblioteca es una vulnerabilidad potencial. Las implementaciones de bibliotecas "seguras" incluyen "The Better String Library", [17] Vstr [18] y Erwin. [19] La biblioteca C del sistema operativo OpenBSD proporciona las funciones strlcpy y strlcat , pero estas son más limitadas que las implementaciones de bibliotecas totalmente seguras.
En septiembre de 2007 se publicó el Informe Técnico 24731, elaborado por el comité de normas C; [20] especifica un conjunto de funciones que se basan en las funciones de E / S y de cadena de la biblioteca C estándar, con parámetros adicionales de tamaño de búfer. Sin embargo, la eficacia de estas funciones con el fin de reducir los desbordamientos de búfer es discutible; requiere la intervención del programador en función de la llamada de función que es equivalente a la intervención que podría hacer que el desbordamiento del búfer de funciones de biblioteca estándar análogas más antiguas sea seguro. [21]
Protección contra desbordamiento del búfer
La protección de desbordamiento de búfer se utiliza para detectar los desbordamientos de búfer más comunes al verificar que la pila no se haya alterado cuando una función regresa. Si ha sido alterado, el programa sale con un fallo de segmentación . Tres de estos sistemas son Libsafe, [22] y los parches StackGuard [23] y ProPolice [24] gcc .
La implementación de Microsoft del modo Prevención de ejecución de datos (DEP) protege explícitamente el puntero al Controlador de excepciones estructurado (SEH) para que no se sobrescriba. [25]
Es posible una protección más sólida de la pila dividiendo la pila en dos: uno para los datos y otro para los retornos de funciones. Esta división está presente en el lenguaje Forth , aunque no fue una decisión de diseño basada en la seguridad. Independientemente, esta no es una solución completa para los desbordamientos del búfer, ya que los datos confidenciales que no sean la dirección de retorno pueden sobrescribirse.
Protección de puntero
Los desbordamientos de búfer funcionan manipulando punteros , incluidas las direcciones almacenadas. PointGuard se propuso como una extensión del compilador para evitar que los atacantes pudieran manipular punteros y direcciones de manera confiable. [26] El enfoque funciona haciendo que el compilador agregue código a punteros de codificación XOR automáticamente antes y después de que se utilicen. En teoría, debido a que el atacante no sabe qué valor se utilizará para codificar / decodificar el puntero, no puede predecir a qué apuntará si lo sobrescribe con un nuevo valor. PointGuard nunca se lanzó, pero Microsoft implementó un enfoque similar a partir de Windows XP SP2 y Windows Server 2003 SP1. [27] En lugar de implementar la protección de punteros como una característica automática, Microsoft agregó una rutina API que se puede llamar. Esto permite un mejor rendimiento (porque no se usa todo el tiempo), pero coloca la carga sobre el programador para saber cuándo es necesario.
Debido a que XOR es lineal, un atacante puede manipular un puntero codificado sobrescribiendo solo los bytes inferiores de una dirección. Esto puede permitir que un ataque tenga éxito si el atacante puede intentar el exploit varias veces o puede completar un ataque haciendo que un puntero apunte a una de varias ubicaciones (como cualquier ubicación dentro de un trineo NOP). [28] Microsoft agregó una rotación aleatoria a su esquema de codificación para abordar esta debilidad de las sobrescrituras parciales. [29]
Protección de espacio ejecutable
La protección del espacio ejecutable es un enfoque para la protección de desbordamiento del búfer que evita la ejecución de código en la pila o en el montón. Un atacante puede usar desbordamientos de búfer para insertar código arbitrario en la memoria de un programa, pero con la protección del espacio ejecutable, cualquier intento de ejecutar ese código provocará una excepción.
Algunas CPU admiten una función denominada bit NX ("No eXecute") o XD ("eXecute Disabled"), que, junto con el software, se pueden utilizar para marcar páginas de datos (como las que contienen la pila y el montón) como legibles y escribible pero no ejecutable.
Algunos sistemas operativos Unix (por ejemplo , OpenBSD , macOS ) se envían con protección de espacio ejecutable (por ejemplo, W ^ X ). Algunos paquetes opcionales incluyen:
- PaX [30]
- Escudo ejecutivo [31]
- Pared abierta [32]
Las variantes más recientes de Microsoft Windows también admiten la protección del espacio ejecutable, denominada Prevención de ejecución de datos . [33] Los complementos patentados incluyen:
- BufferShield [34]
- StackDefender [35]
La protección del espacio ejecutable generalmente no protege contra ataques de retorno a libc o cualquier otro ataque que no dependa de la ejecución del código de los atacantes. Sin embargo, en los sistemas de 64 bits que utilizan ASLR , como se describe a continuación, la protección del espacio ejecutable hace que sea mucho más difícil ejecutar tales ataques.
Aleatorización del diseño del espacio de direcciones
La aleatorización del diseño del espacio de direcciones (ASLR) es una característica de seguridad informática que implica organizar las posiciones de las áreas de datos clave, que generalmente incluyen la base del ejecutable y la posición de las bibliotecas, el montón y la pila, de forma aleatoria en el espacio de direcciones de un proceso.
La aleatorización de las direcciones de memoria virtual en las que se pueden encontrar funciones y variables puede hacer que la explotación de un desbordamiento del búfer sea más difícil, pero no imposible. También obliga al atacante a adaptar el intento de explotación al sistema individual, lo que frustra los intentos de los gusanos de Internet . [36] Un método similar, pero menos eficaz, consiste en reajustar procesos y bibliotecas en el espacio de direcciones virtuales.
Inspección profunda de paquetes
El uso de la inspección profunda de paquetes (DPI) puede detectar, en el perímetro de la red, intentos remotos muy básicos para explotar los desbordamientos del búfer mediante el uso de firmas de ataque y heurísticas . Estos pueden bloquear paquetes que tienen la firma de un ataque conocido, o si se detecta una serie larga de instrucciones de No Operación (conocidas como trineo NOP), estas se usaron una vez cuando la ubicación de la carga útil del exploit es ligeramente variable .
El escaneo de paquetes no es un método efectivo, ya que solo puede prevenir ataques conocidos y hay muchas formas de codificar un trineo NOP. El código de shell utilizado por los atacantes puede hacerse alfanumérico , metamórfico o auto-modificable para evadir la detección por escáneres de paquetes heurísticos y sistemas de detección de intrusos .
Pruebas
Verificar los desbordamientos del búfer y corregir los errores que los causan naturalmente ayuda a prevenir los desbordamientos del búfer. Una técnica automatizada común para descubrirlos es el fuzzing . [37] Las pruebas de caso Edge también pueden descubrir desbordamientos de búfer, al igual que el análisis estático. [38] Una vez que se detecta un posible desbordamiento del búfer, se debe parchear; esto hace que el enfoque de prueba sea útil para el software que está en desarrollo, pero menos útil para el software heredado que ya no se mantiene ni se admite.
Historia
Los desbordamientos de búfer se entendieron y documentaron parcialmente públicamente ya en 1972, cuando el Estudio de planificación de tecnología de seguridad informática presentó la técnica: "El código que realiza esta función no verifica las direcciones de origen y destino correctamente, lo que permite que partes del monitor se superpongan con el usuario. Esto se puede utilizar para inyectar código en el monitor que permitirá al usuario tomar el control de la máquina ". [39] Hoy en día, el monitor se denominaría kernel.
La primera explotación hostil documentada de un desbordamiento de búfer fue en 1988. Fue uno de los varios exploits utilizados por el gusano Morris para propagarse a través de Internet. El programa explotado era un servicio en Unix llamado finger . [40] Más tarde, en 1995, Thomas Lopatic redescubrió independientemente el desbordamiento del búfer y publicó sus hallazgos en la lista de correo de seguridad de Bugtraq . [41] Un año más tarde, en 1996, Elias Levy (también conocido como Aleph One) publicó en la revista Phrack el artículo "Smashing the Stack for Fun and Profit", [42] una introducción paso a paso a la explotación de pilas vulnerabilidades de desbordamiento de búfer.
Desde entonces, al menos dos gusanos de Internet importantes se han aprovechado de los desbordamientos de búfer para comprometer una gran cantidad de sistemas. En 2001, el gusano Code Red aprovechó un desbordamiento de búfer en Internet Information Services (IIS) 5.0 de Microsoft [43] y en 2003 el gusano SQL Slammer comprometió las máquinas que ejecutan Microsoft SQL Server 2000 . [44]
En 2003, los desbordamientos de búfer presentes en los juegos de Xbox con licencia se explotaron para permitir que el software sin licencia, incluidos los juegos caseros , se ejecutara en la consola sin necesidad de modificaciones de hardware, conocidas como modchips . [45] El PS2 Independence Exploit también usó un desbordamiento de búfer para lograr lo mismo para PlayStation 2 . El truco de Crepúsculo logró lo mismo con la Wii , usando un desbordamiento de búfer en The Legend of Zelda: Twilight Princess .
Ver también
- Mil millones de risas
- Búfer sobreleído
- Convenciones de codificación
- La seguridad informática
- Fin del documento
- Desbordamiento del montón
- ping de la muerte
- Escáner de puerto
- Ataque de retorno a libc
- Sistema de seguridad crítica
- Sistema operativo centrado en la seguridad
- Código auto modificable
- Calidad del software
- Shellcode
- Desbordamiento del búfer de pila
- Cadena de formato incontrolada
Referencias
- ^ "CORE-2007-0219: desbordamiento de búfer de kernel remoto IPv6 mbufs de OpenBSD" . Consultado el 15 de mayo de 2007 .
- ^ "Objetivos de desbordamiento modernos" (PDF) . Consultado el 5 de julio de 2013 .
- ^ "La base de datos de Metasploit Opcode" . Archivado desde el original el 12 de mayo de 2007 . Consultado el 15 de mayo de 2007 .
- ^ "Boletín de seguridad de Microsoft Technet MS04-028" . Archivado desde el original el 4 de agosto de 2011 . Consultado el 15 de mayo de 2007 .
- ^ "Creación de Shellcode arbitrario en cadenas expandidas Unicode" (PDF) . Archivado desde el original (PDF) el 2006-01-05 . Consultado el 15 de mayo de 2007 .
- ^ Vangelis (8 de diciembre de 2004). "Explotación de desbordamiento basado en pila: Introducción a la técnica de desbordamiento clásica y avanzada" . Wowhacker a través de Neworder. Archivado desde el original (texto) el 18 de agosto de 2007. Cite journal requiere
|journal=
( ayuda ) - ^ Balaban, Murat. "Desbordamientos de búfer desmitificados" (texto) . Enderunix.org. Cite journal requiere
|journal=
( ayuda ) - ^ Akritidis, P .; Evangelos P. Markatos; M. Polychronakis; Kostas D. Anagnostakis (2005). "STRIDE: Detección de trineo polimórfico mediante análisis de secuencia de instrucciones". (PDF) . Actas de la 20ª Conferencia Internacional de Seguridad de la Información de IFIP (IFIP / SEC 2005) . Conferencia Internacional de Seguridad de la Información IFIP. Archivado desde el original (PDF) el 1 de septiembre de 2012 . Consultado el 4 de marzo de 2012 .
- ^ Klein, Christian (septiembre de 2004). "Desbordamiento de búfer" (PDF) . Archivado desde el original (PDF) el 28 de septiembre de 2007. Cite journal requiere
|journal=
( ayuda ) - ^ Shah, Saumil (2006). "Escribir complementos de Metasploit: de la vulnerabilidad a la explotación" (PDF) . Hack In The Box . Kuala Lumpur . Consultado el 4 de marzo de 2012 .
- ^ Manual del desarrollador de software de arquitecturas Intel 64 e IA-32 Volumen 2A: Referencia del conjunto de instrucciones, AM (PDF) . Corporación Intel. Mayo de 2007. págs. 3–508. Archivado desde el original (PDF) el 29 de noviembre de 2007.
- ^ Álvarez, Sergio (5 de septiembre de 2004). "Proceso de Vuln-Dev de la vida real de Win32 Stack BufferOverFlow" (PDF) . Consultoría de seguridad informática . Consultado el 4 de marzo de 2012 . Cite journal requiere
|journal=
( ayuda ) - ^ Ukai, Yuji; Soeder, Derek; Permeh, Ryan (2004). "Dependencias del entorno en la explotación de Windows" . BlackHat Japón . Japón: eEye Digital Security . Consultado el 4 de marzo de 2012 .
- ^ a b https://www.owasp.org/index.php/Buffer_OverflowsBuffer Overflows artículo sobre OWASP Archivado 2016-08-29 en Wayback Machine
- ^ "vector :: at - Referencia de C ++" . Cplusplus.com . Consultado el 27 de marzo de 2014 .
- ^ http://wiretap.area.com/Gopher/Library/Techdoc/Virus/inetvir.823 [ enlace muerto permanente ]
- ^ "La mejor biblioteca de cadenas" .
- ^ "La página de inicio de Vstr" . Archivado desde el original el 5 de marzo de 2017 . Consultado el 15 de mayo de 2007 .
- ^ "La página de inicio de Erwin" . Consultado el 15 de mayo de 2007 .
- ^ Organización Internacional de Normalización (2007). "Tecnología de la información - Lenguajes de programación, sus entornos e interfaces de software del sistema - Extensiones a la biblioteca C - Parte 1: Interfaces de verificación de límites" . Plataforma de navegación en línea ISO .
- ^ "Iniciativa de codificación segura CERT" . Consultado el 30 de julio de 2007 .[ enlace muerto permanente ]
- ^ "Libsafe en FSF.org" . Consultado el 20 de mayo de 2007 .
- ^ "StackGuard: detección adaptativa automática y prevención de ataques de desbordamiento de búfer por Cowan et al" (PDF) . Consultado el 20 de mayo de 2007 .
- ^ "ProPolice en X.ORG" . Archivado desde el original el 12 de febrero de 2007 . Consultado el 20 de mayo de 2007 .
- ^ "Omitir la prevención de ejecución de datos aplicada por hardware de Windows" . Archivado desde el original el 30 de abril de 2007 . Consultado el 20 de mayo de 2007 .
- ^ "12º Simposio de Seguridad de USENIX - Documento técnico" . www.usenix.org . Consultado el 3 de abril de 2018 .
- ^ "Protección contra Pointer Subterfuge (¡Un poco!)" . msdn.com . Archivado desde el original el 2 de mayo de 2010 . Consultado el 3 de abril de 2018 .
- ^ "USENIX - Asociación de sistemas informáticos avanzados" (PDF) . www.usenix.org . Consultado el 3 de abril de 2018 .
- ^ "Protección contra Pointer Subterfuge (Redux)" . msdn.com . Archivado desde el original el 19 de diciembre de 2009 . Consultado el 3 de abril de 2018 .
- ^ "PaX: Página de inicio del equipo PaX" . Consultado el 3 de junio de 2007 .
- ^ "KernelTrap.Org" . Archivado desde el original el 29 de mayo de 2012 . Consultado el 3 de junio de 2007 .
- ^ "Parche 2.4.34-ow1 del kernel de Openwall Linux" . Archivado desde el original el 19 de febrero de 2012 . Consultado el 3 de junio de 2007 .
- ^ "Microsoft Technet: prevención de ejecución de datos" . Archivado desde el original el 22 de junio de 2006 . Consultado el 30 de junio de 2006 .
- ^ "BufferShield: prevención de la explotación de desbordamiento de búfer para Windows" . Consultado el 3 de junio de 2007 .
- ^ "Defensor de pila de NGSec" . Archivado desde el original el 13 de mayo de 2007 . Consultado el 3 de junio de 2007 .
- ^ "PaX en GRSecurity.net" . Consultado el 3 de junio de 2007 .
- ^ "The Exploitant - Información de seguridad y tutoriales" . Consultado el 29 de noviembre de 2009 .
- ^ Larochelle, David; Evans, David (13 de agosto de 2001). "Detección estática de posibles vulnerabilidades de desbordamiento de búfer" . Simposio de seguridad de USENIX . 32 .
- ^ "Estudio de planificación de tecnología de seguridad informática" (PDF) . pag. 61. Archivado desde el original (PDF) el 21 de julio de 2011 . Consultado el 2 de noviembre de 2007 .
- ^ " " Un recorrido por el gusano "por Donn Seeley, Universidad de Utah" . Archivado desde el original el 20 de mayo de 2007 . Consultado el 3 de junio de 2007 .
- ^ "Archivo de lista de correo de seguridad de Bugtraq" . Archivado desde el original el 1 de septiembre de 2007 . Consultado el 3 de junio de 2007 .
- ^ " " Rompiendo la pila por diversión y ganancias "por Aleph One" . Consultado el 5 de septiembre de 2012 .
- ^ "eEye Digital Security" . Consultado el 3 de junio de 2007 .
- ^ "Boletín de seguridad de Microsoft Technet MS02-039" . Archivado desde el original el 7 de marzo de 2008 . Consultado el 3 de junio de 2007 .
- ^ "Hacker rompe la protección de Xbox sin mod-chip" . Archivado desde el original el 27 de septiembre de 2007 . Consultado el 3 de junio de 2007 .
enlaces externos
- "Descubrimiento y explotación de una vulnerabilidad de desbordamiento de búfer remoto en un servidor FTP" por Raykoid666
- "Rompiendo la pila por diversión y ganancias" por Aleph One
- Gerg, Isaac (2 de mayo de 2005). "Una descripción general y un ejemplo de la vulnerabilidad de desbordamiento de búfer" (PDF) . IAnewsletter . Centro de Análisis de Tecnología de Aseguramiento de la Información . 7 (4): 16-21. Archivado desde el original (PDF) el 27 de septiembre de 2006 . Consultado el 17 de marzo de 2019 .
- Estándares de codificación segura CERT
- Iniciativa de codificación segura CERT
- Codificación segura en C y C ++
- SANS: dentro del ataque de desbordamiento de búfer
- "Avances en desbordamientos de memoria adyacente" por Nomenumbra
- Una comparación de implementaciones y debilidades de prevención de desbordamiento de búfer
- Más informes de seguridad sobre desbordamientos de búfer
- Capítulo 12: Escribiendo Exploits III desde Sockets, Shellcode, Porting & Coding: Exploits de ingeniería inversa y codificación de herramientas para profesionales de seguridad por James C. Foster ( ISBN 1-59749-005-9 ). Explicación detallada de cómo usar Metasploit para desarrollar un exploit de desbordamiento de búfer desde cero.
- Estudio de planificación de tecnología de seguridad informática , James P. Anderson, ESD-TR-73-51, ESD / AFSC, Hanscom AFB, Bedford, MA 01731 (octubre de 1972) [NTIS AD-758 206]
- "Desbordamientos de búfer: anatomía de un exploit" de Nevermore
- Programación segura con GCC y GLibc (2008), por Marcel Holtmann
- "Criação de Exploits com Buffer Overflor - Parte 0 - Um pouco de teoria" (2018), de Helvio Junior (M4v3r1ck)