Desbordamiento de búfer

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, , y un entero big-endiana de dos bytes , .b

char a [ 8 ] = "" ; unsigned short b = 1979 ;

Inicialmente, ano contiene nada más que cero bytes y bcontiene el número 1979.

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 de longitud y se codifica en 10 bytes incluyendo el terminador nulo, pero asolo puede ocupar 8 bytes. Al no comprobar la longitud de la cadena, también sobrescribe el valor de b:

bEl valor de ahora ha sido reemplazado inadvertidamente por un número formado a partir de una parte de la cadena de caracteres. En este ejemplo, "e" seguido de un byte cero se convertiría en 25856.

En ocasiones, el sistema operativo puede detectar que se escriben datos más allá del límite de la memoria asignada, lo que genera un error de fallo de segmentación que finaliza el proceso.

Para evitar que se produzca un desbordamiento de búfer en este ejemplo, la llamada a strcpypodría reemplazarse por 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 en más de esta cantidad de datos a:

strlcpy ( a , "excesivo" , sizeof ( a ));

strlcpyCuando esté disponible, se prefiere la función de la biblioteca strncpyque no termina con un carácter nulo el búfer de destino si la longitud de la cadena de origen es mayor o igual al tamaño del búfer (el tercer argumento pasado a la función). Por lo tanto, apuede que no termine con un carácter nulo y no se pueda tratar como una cadena válida de estilo C.

Existen varias formas de manipular un programa explotando los desbordamientos de búfer basados ​​en la pila:

• Modificar el comportamiento del programa sobrescribiendo una variable local ubicada cerca del búfer vulnerable en la pila;
• Al sobrescribir la dirección de retorno en un marco de pila para que apunte 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;
• Sobrescribiendo un puntero de función ^{[ 4 ]} o un manejador de excepciones para que apunte al shellcode, que posteriormente se ejecuta;
• Sobrescribiendo una variable local (o puntero) de un marco de pila diferente, que posteriormente será utilizado por la función propietaria de ese marco. ^{[ 5 ]}

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 para afectar el desbordamiento del búfer de la pila es impredecible, explotar dicho desbordamiento para provocar la ejecución remota de código se vuelve mucho más difícil. Una técnica que se puede utilizar para explotar este tipo de desbordamiento de búfer se denomina " trampolín ". En este caso, el atacante encontrará un puntero al búfer de la pila vulnerable y calculará la ubicación de su shellcode en relación con ese puntero. A continuación, el atacante utilizará la sobrescritura para saltar a una instrucción que ya se encuentra en la memoria, la cual realizará un segundo salto, esta vez en relación con el puntero. Ese segundo salto ramificará la ejecución hacia el shellcode. Las instrucciones adecuadas suelen estar presentes en código extenso. 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 . ^{[ 6 ]}

Un desbordamiento de búfer en el área de datos del montón se denomina desbordamiento de montón y puede explotarse de forma distinta a los desbordamientos en la pila. La memoria del montón es asignada dinámicamente por la aplicación en tiempo de ejecución y normalmente contiene datos del programa. La explotación se realiza corrompiendo estos datos de maneras específicas para provocar que la aplicación sobrescriba estructuras internas, como punteros a listas enlazadas. La técnica canónica de desbordamiento de montón sobrescribe el enlace de asignación dinámica de memoria (como los metadatos de malloc ) y utiliza el intercambio de punteros resultante para sobrescribir un puntero a una función del programa.

La vulnerabilidad de GDI+ de Microsoft en el manejo de JPEGs es un ejemplo del peligro que puede presentar un desbordamiento de montón. ^{[ 7 ]}

La manipulación del búfer, que ocurre antes de su lectura o ejecución, puede provocar el fracaso de un intento de explotación. Estas manipulaciones pueden mitigar la amenaza de explotación, pero no necesariamente la imposibilitan. Las manipulaciones podrían incluir la conversión a mayúsculas o minúsculas, la eliminación de metacaracteres y el filtrado de cadenas no alfanuméricas . Sin embargo, existen técnicas para eludir estos filtros y manipulaciones, como el shellcode alfanumérico , el código polimórfico , el código automodificable y los ataques de retorno a libc . Los mismos métodos pueden utilizarse para evitar la detección por parte de los sistemas de detección de intrusiones . En algunos casos, como cuando el código se convierte a Unicode , ^{[ 8 ]} los divulgadores han presentado erróneamente la amenaza de la vulnerabilidad como una simple denegación de servicio, cuando en realidad es posible la ejecución remota de código arbitrario.

En los exploits reales, existen diversos desafíos que deben superarse para que funcionen de manera confiable. Estos factores incluyen bytes nulos en las direcciones, variabilidad en la ubicación del shellcode, diferencias entre entornos y diversas contramedidas en funcionamiento.

Técnica de trineo NOP

Un NOP-sled es la técnica más antigua y conocida para explotar desbordamientos de búfer de pila. ^{[ 9 ]} Resuelve el problema de encontrar la dirección exacta del búfer aumentando efectivamente el tamaño del área objetivo. Para ello, se corrompen secciones mucho más grandes de la pila con la instrucción de máquina no-op . Al final de los datos proporcionados por el atacante, después de las instrucciones no-op, el atacante coloca una instrucción para realizar un salto relativo a la parte superior del búfer donde se encuentra el shellcode . Esta colección de no-ops se denomina "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á" por las no-ops hasta que sea redirigida al código malicioso real mediante el salto al final. Esta técnica requiere que el atacante adivine dónde se encuentra el NOP-sled en la pila en lugar del shellcode comparativamente pequeño. ^{[ 10 ]}

Debido a la popularidad de esta técnica, muchos proveedores de sistemas de prevención de intrusiones buscan este patrón de instrucciones de máquina no-op en un intento de detectar el shellcode en uso. Un NOP-sled no necesariamente contiene solo instrucciones de máquina no-op tradicionales. Cualquier instrucción que no corrompa el estado de la máquina hasta el punto de impedir la ejecución del shellcode puede usarse en lugar del no-op asistido por hardware. Como resultado, se ha vuelto común que los creadores de exploits compongan el no-op sled con instrucciones elegidas al azar que no tendrán ningún efecto real en la ejecución del shellcode. ^{[ 11 ]}

Aunque este método mejora considerablemente las probabilidades de éxito de un ataque, no está exento de problemas. Los exploits que utilizan esta técnica aún dependen en cierta medida de la suerte para adivinar desplazamientos en la pila que se encuentren dentro de la región NOP-sled. ^{[ 12 ]} Una suposición incorrecta generalmente provocará el bloqueo del programa objetivo y podría alertar al administrador del sistema sobre las actividades del atacante. Otro problema es que el NOP-sled requiere una cantidad de memoria mucho mayor para almacenar un NOP-sled lo suficientemente grande como para ser útil. 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 baja (es decir, no hay mucho espacio entre el final del marco de pila actual y el inicio de la pila). A pesar de sus problemas, el NOP-sled suele ser el único método que funciona para una plataforma, entorno o situación determinada, y como tal, sigue siendo una técnica importante.

La técnica de salto a la dirección almacenada en un registro

La técnica de "salto a registro" permite explotar de forma fiable los desbordamientos de búfer de pila sin necesidad de espacio adicional para una secuencia NOP y sin tener que adivinar los desplazamientos de la pila. La estrategia consiste en sobrescribir el puntero de retorno con algo que provoque que el programa salte a un puntero conocido almacenado en un registro que apunta al búfer controlado y, por lo tanto, al shellcode. Por ejemplo, si el registro A contiene un puntero al inicio de un búfer, cualquier salto o llamada que utilice ese registro como operando puede usarse para obtener el control del flujo de ejecución. ^{[ 13 ]}

En la práctica, un programa puede no contener intencionalmente instrucciones para saltar a un registro específico. La solución tradicional consiste en encontrar una instancia no intencional de un código de operación adecuado en una ubicación fija dentro de la memoria del programa. La figura E de la izquierda contiene un ejemplo de dicha instancia no intencional de la jmp espinstrucción i386. El código de operación para esta instrucción es FF E4. ^{[ 14 ]} Esta secuencia de dos bytes se puede encontrar a un desplazamiento de un byte desde el inicio de la instrucción call DbgPrinten la dirección 0x7C941EED. Si un atacante sobrescribe la dirección de retorno del programa con esta dirección, el programa primero saltará a 0x7C941EED, interpretará el código de operación FF E4como la jmp espinstrucción y luego saltará a la parte superior de la pila y ejecutará el código del atacante. ^{[ 15 ]}

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 al ejecutarse. Por esta razón, esta es la técnica más utilizada en gusanos informáticos que explotan vulnerabilidades de desbordamiento de búfer de pila. ^{[ 16 ]}

Este método también permite colocar shellcode después de la dirección de retorno sobrescrita en la plataforma Windows . Dado que los ejecutables se basan principalmente en la dirección 0x00400000y 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 shellcode al tamaño del búfer, lo que puede ser demasiado restrictivo. Las DLL se encuentran en memoria alta (por encima de 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. Utilizado de esta manera, el método a menudo se denominaTrampolín DLL .

El lenguaje ensamblador , C y C++ son lenguajes de programación populares que son vulnerables al desbordamiento de búfer en parte porque permiten el acceso directo a la memoria y no son fuertemente tipados . ^{[ 17 ]} C no proporciona protección integrada contra el acceso o la sobrescritura de datos en ninguna 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 pueden realizar opcionalmente comprobaciones de límites si el programador llama explícitamente a las comprobaciones mientras accede a los datos. Por ejemplo, una vectorfunción miembro at()de realiza una comprobación de límites y lanza una out_of_rangeexcepción si la comprobación de límites falla. ^{[ 18 ]} Sin embargo, C++ se comporta igual que C si la comprobació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 que no permiten el acceso directo a la memoria, como COBOL, Java, Eiffel, Python y otros, evitan el desbordamiento de búfer en la mayoría de los casos. ^{[ 17 ]} Muchos lenguajes de programación distintos de C o C++ proporcionan comprobación en tiempo de ejecución y, en algunos casos, incluso en tiempo de compilación, lo que puede enviar una advertencia o generar una excepción, mientras que C o C++ sobrescribirían los datos y continuarían ejecutando instrucciones hasta obtener resultados erróneos, lo que podría provocar que el programa falle. Ejemplos de estos lenguajes incluyen Ada , Eiffel , Lisp , Modula-2 , Smalltalk , OCaml y algunos lenguajes de programación de sistemas como Cyclone , Rust y D. Los entornos de bytecode de Java y .NET Framework también requieren comprobación de límites en todos los arrays. Casi todos los lenguajes interpretados protegen contra el desbordamiento de búfer, señalando una condición de error bien definida. Los lenguajes que proporcionan suficiente información de tipo para realizar la comprobación de límites suelen ofrecer una opción para habilitarla o deshabilitarla. El análisis estático del código puede eliminar muchas comprobaciones dinámicas de límites y tipos, pero las implementaciones deficientes y los casos incómodos pueden disminuir significativamente el rendimiento. Los ingenieros de software deben considerar cuidadosamente las ventajas y desventajas en cuanto a seguridad y rendimiento al decidir qué lenguaje y configuración del compilador utilizar.

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 los búferes como contenedores de tipos de datos. Los desbordamientos de búfer se pueden evitar manteniendo un alto grado de corrección en el código que realiza la gestión de búferes. También se ha recomendado desde hace tiempo evitar las funciones de la biblioteca estándar que no tienen comprobación de límites, como y gets. El gusano Morris explotó una llamada en fingerd . ^{[ 19 ]}scanfstrcpygets

Las bibliotecas de tipos de datos abstractos bien escritas y probadas que centralizan y realizan automáticamente la gestión de búferes, incluyendo la comprobación de límites, pueden reducir la aparición y el impacto de los desbordamientos de búfer. Los tipos de datos principales en lenguajes en los que los desbordamientos de búfer son comunes son las cadenas y los arreglos. Por lo tanto, las bibliotecas que previenen los desbordamientos de búfer en estos tipos de datos pueden proporcionar la gran mayoría de la cobertura necesaria. Sin embargo, no usar correctamente estas bibliotecas seguras puede resultar en desbordamientos de búfer y otras vulnerabilidades, y naturalmente cualquier error en la biblioteca también es una vulnerabilidad potencial. Las implementaciones de bibliotecas "seguras" incluyen "The Better String Library", ^{[ 20 ]} Vstr ^{[ 21 ]} y Erwin. ^{[ 22 ]} La biblioteca C del sistema operativo OpenBSD proporciona las funciones strlcpy y strlcat , pero estas son más limitadas que las implementaciones de bibliotecas seguras completas.

En septiembre de 2007, se publicó el Informe Técnico 24731, elaborado por el comité de estándares de C. ^{[ 23 ]} Este informe especifica un conjunto de funciones basadas en las funciones de cadena y E/S de la biblioteca estándar de C, con parámetros adicionales para el tamaño del búfer. Sin embargo, la eficacia de estas funciones para reducir los desbordamientos de búfer es cuestionable. Requieren la intervención del programador en cada llamada a la función, lo que equivale a la intervención necesaria para que las funciones análogas de la biblioteca estándar más antiguas sean seguras frente a desbordamientos de búfer. ^{[ 24 ]}

La protección contra desbordamientos de búfer se utiliza para detectar los desbordamientos de búfer más comunes comprobando que la pila no se haya modificado cuando una función finaliza. Si se ha modificado, el programa termina con un error de segmentación . Tres de estos sistemas son Libsafe, ^{[ 25 ]} y los parches StackGuard ^{[ 26 ]} y ProPolice ^{[ 27 ]} de gcc .

La implementación del modo de Prevención de Ejecución de Datos (DEP) de Microsoft protege explícitamente el puntero al Controlador de Excepciones Estructuradas (SEH) para que no se sobrescriba. ^{[ 28 ]}

Es posible mejorar la protección de la pila dividiéndola en dos: una para datos y otra para el retorno de funciones. Esta división está presente en el lenguaje Forth , aunque no fue una decisión de diseño basada en la seguridad. Sin embargo, esta no es una solución completa para los desbordamientos de búfer, ya que aún se pueden sobrescribir datos confidenciales distintos de la dirección de retorno.

Este tipo de protección tampoco es del todo precisa, ya que no detecta todos los ataques. Los sistemas como StackGuard se centran más en el comportamiento de los ataques, lo que los hace más eficientes y rápidos en comparación con los sistemas de verificación de rango. ^{[ 29 ]}

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 manipularan de forma fiable punteros y direcciones. ^{[ 30 ]} El enfoque funciona haciendo que el compilador añada código para codificar automáticamente los punteros mediante XOR antes y después de su uso. Teóricamente, dado que el atacante no sabe qué valor se utilizará para codificar y decodificar el puntero, no se puede predecir a qué apuntará el puntero si se sobrescribe con un nuevo valor. PointGuard nunca se publicó, pero Microsoft implementó un enfoque similar a partir de Windows XP SP2 y Windows Server 2003 SP1. ^{[ 31 ]} En lugar de implementar la protección de punteros como una característica automática, Microsoft añadió una rutina API que se puede llamar. Esto permite un mejor rendimiento (porque no se utiliza todo el tiempo), pero obliga al programador a saber cuándo es necesario su uso.

Debido a que la operación XOR es lineal, un atacante podría 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 la explotación varias veces o completar un ataque haciendo que un puntero apunte a una de varias ubicaciones (como cualquier ubicación dentro de una secuencia NOP). ^{[ 32 ]} Microsoft agregó una rotación aleatoria a su esquema de codificación para abordar esta vulnerabilidad a las sobrescrituras parciales. ^{[ 33 ]}

La protección del espacio ejecutable es un método para protegerse contra desbordamientos de búfer que impide la ejecución de código en la pila o el montón. Un atacante podría 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 llamada bit NX ("No eXecute") o XD ("eXecute Disabled"), que, junto con el software, se puede utilizar para marcar páginas de datos (como las que contienen la pila y el montón) como legibles y escribibles, pero no ejecutables.

Algunos sistemas operativos Unix (por ejemplo, OpenBSD , macOS ) incluyen protección del espacio ejecutable (por ejemplo, W^X ). Algunos paquetes opcionales incluyen:

• PaX ^{[ 34 ]}
• Escudo ejecutivo ^{[ 35 ]}
• Openwall ^{[ 36 ]}

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 . ^{[ 37 ]} Los complementos propietarios incluyen:

• BufferShield ^{[ 38 ]}
• StackDefender ^{[ 39 ]}

La protección del espacio ejecutable generalmente no protege contra ataques de retorno a libc ni contra ningún otro ataque que no dependa de la ejecución del código del atacante. Sin embargo, en sistemas de 64 bits que utilizan ASLR , como se describe a continuación, la protección del espacio ejecutable dificulta considerablemente la ejecución de dichos ataques.

CHERI (Capability Hardware Enhanced RISC Instructions) es una tecnología de procesadores diseñada para mejorar la seguridad. Opera a nivel de hardware al proporcionar un tipo de acceso restringido por hardware (una capacidad CHERI) que autoriza el acceso a la memoria. Los punteros tradicionales se reemplazan por direcciones acompañadas de metadatos que limitan el acceso a cualquier puntero.

La aleatorización del diseño del espacio de direcciones (ASLR, por sus siglas en inglés) es una característica de seguridad informática que consiste en organizar aleatoriamente las posiciones de las áreas de datos clave, que normalmente incluyen la base del ejecutable y la posición de las bibliotecas, el montón y la pila, en el espacio de direcciones de un proceso.

La aleatorización de las direcciones de memoria virtual donde se encuentran las funciones y variables puede dificultar, aunque no imposibilitar, la explotación de un desbordamiento de búfer. Además, obliga al atacante a adaptar el intento de explotación al sistema individual, lo que frustra los intentos de los gusanos informáticos . ^{[ 40 ]} Un método similar, pero menos efectivo, consiste en reorganizar los procesos y las bibliotecas en el espacio de direcciones virtuales.

El uso de la inspección profunda de paquetes (DPI) permite detectar, en el perímetro de la red, intentos remotos muy básicos de explotar desbordamientos de búfer mediante firmas de ataque y heurísticas . Esta técnica puede bloquear paquetes que presenten la firma de un ataque conocido. Anteriormente se utilizaba en situaciones en las que se detectaba una larga serie de instrucciones de no operación (conocida como NOP-sled) y la ubicación de la carga útil del exploit era ligeramente variable.

El escaneo de paquetes no es un método eficaz, ya que solo puede prevenir ataques conocidos y existen muchas maneras de codificar un NOP-sled. El shellcode utilizado por los atacantes puede ser alfanumérico , metamórfico o automodificable para evadir la detección por parte de los escáneres de paquetes heurísticos y los sistemas de detección de intrusiones .

La comprobación de desbordamientos de búfer y la corrección de los errores que los provocan ayudan a prevenirlos. Una técnica automatizada común para detectarlos es el fuzzing . ^{[ 41 ]} Las pruebas de casos extremos también pueden descubrir desbordamientos de búfer, al igual que el análisis estático. ^{[ 42 ]} Una vez detectado un posible desbordamiento de búfer, debe corregirse. Esto hace que el enfoque de pruebas sea útil para el software en desarrollo, pero menos útil para el software heredado que ya no recibe mantenimiento ni soporte.