Protección contra desbordamiento de búfer

Los canarios de terminación se basan en la observación de que la mayoría de los ataques de desbordamiento de búfer se fundamentan en ciertas operaciones de cadena que terminan en terminadores de cadena. La respuesta a esta observación es que los canarios se construyen con terminadores nulos , CR , LF y FF . Como resultado, el atacante debe escribir un carácter nulo antes de escribir la dirección de retorno para evitar alterar el canario. Esto previene ataques que utilizan strcpy()otros métodos que devuelven un valor al copiar un carácter nulo, aunque el resultado indeseado es que el canario es conocido. Incluso con esta protección, un atacante podría potencialmente sobrescribir el canario con su valor conocido e información de control con valores que no coinciden, eludiendo así el código de verificación del canario, que se ejecuta poco antes de la instrucción de retorno de llamada del procesador específico.

Los valores aleatorios de tipo canario se generan aleatoriamente, generalmente mediante un demonio que recopila entropía , para evitar que un atacante conozca su valor. Normalmente, no es lógicamente posible ni plausible leer el valor del canario para explotarlo; se trata de un valor seguro conocido únicamente por quienes necesitan conocerlo : en este caso, el código de protección contra desbordamiento de búfer.

Normalmente, se genera un canario aleatorio al inicializar el programa y se almacena en una variable global . Esta variable suele rellenarse con páginas no mapeadas, de modo que cualquier intento de leerla mediante técnicas que exploten vulnerabilidades para acceder a la RAM provoca un fallo de segmentación y la finalización del programa. Aun así, podría ser posible leer el canario si el atacante conoce su ubicación o consigue que el programa lea desde la pila.

Los valores aleatorios XOR son valores aleatorios que se modifican mediante la operación XOR utilizando la totalidad o parte de los datos de control. De esta forma, si el valor o los datos de control se ven alterados, el valor resultante es incorrecto.

Los canarios XOR aleatorios presentan las mismas vulnerabilidades que los canarios aleatorios, con la diferencia de que el método de "lectura de la pila" para obtener el canario es algo más complejo. El atacante debe obtener el canario, el algoritmo y los datos de control para regenerar el canario original necesario para burlar la protección.

Además, los canarios XOR aleatorios pueden proteger contra un tipo específico de ataque que consiste en desbordar un búfer en una estructura hacia un puntero para modificarlo y que apunte a un dato de control. Debido a la codificación XOR, el canario fallará si se modifican los datos de control o el valor de retorno. Gracias al puntero, los datos de control o el valor de retorno pueden modificarse sin desbordar el canario.

Si bien estos mecanismos de seguridad protegen los datos de control para que no sean alterados por punteros modificados, no protegen ningún otro dato ni los propios punteros. Los punteros a funciones, en particular, representan un problema, ya que pueden desbordarse y ejecutar código malicioso al ser llamados.

La protección contra el desbordamiento de pila fue implementada por primera vez por StackGuard en 1997 y publicada en el Simposio de Seguridad USENIX de 1998. ^{[ 11 ]} StackGuard se introdujo como un conjunto de parches para el backend Intel x86 de GCC 2.7. StackGuard se mantuvo para la distribución Immunix Linux desde 1998 hasta 2003, y se amplió con implementaciones para canarios de terminador, aleatorios y XOR aleatorios. Se sugirió la inclusión de StackGuard en GCC 3.x en las Actas de la Cumbre GCC 2003, ^{[ 12 ]} pero esto nunca se logró.

Entre 2001 y 2005, IBM desarrolló parches para GCC que protegían contra el desbordamiento de pila, conocidos como ProPolice . ^{[ 13 ]} Esta modificación mejoró la idea de StackGuard colocando búferes después de los punteros locales y los argumentos de las funciones en el marco de pila. Esto ayudó a evitar la corrupción de punteros, impidiendo el acceso a ubicaciones de memoria arbitrarias.

Los ingenieros de Red Hat identificaron problemas con ProPolice y, en 2005, reimplementaron la protección contra el desbordamiento de pila para su inclusión en GCC 4.1. ^{[ 14 ] [ 15 ]} Este trabajo introdujo la -fstack-protectorbandera, que protege solo algunas funciones vulnerables, y la -fstack-protector-allbandera, que protege todas las funciones, independientemente de si lo necesitan o no. ^{[ 16 ]}

En 2012, los ingenieros de Google implementaron la -fstack-protector-strongbandera para lograr un mejor equilibrio entre seguridad y rendimiento. ^{[ 17 ]} Esta bandera protege más tipos de funciones vulnerables que -fstack-protector, pero no todas las funciones, proporcionando un mejor rendimiento que -fstack-protector-all. Está disponible en GCC desde su versión 4.9. ^{[ 18 ]}

Todos los paquetes de Fedora se compilan con -fstack-protectordesde Fedora Core 5 y -fstack-protector-strongdesde Fedora 20. ^{[ 19 ] [ 20 ]} La mayoría de los paquetes en Ubuntu se compilan con -fstack-protectordesde 6.10. ^{[ 21 ]} Todos los paquetes de Arch Linux se compilan con -fstack-protectordesde 2011. ^{[ 22 ]} Todos los paquetes de Arch Linux compilados desde el 4 de mayo de 2014 usan -fstack-protector-strong. ^{[ 23 ]} La protección de pila solo se usa para algunos paquetes en Debian , ^{[ 24 ]} y solo para el sistema base de FreeBSD desde 8.0. ^{[ 25 ]} La protección de pila es estándar en ciertos sistemas operativos, incluidos OpenBSD , ^{[ 26 ]} Hardened Gentoo ^{[ 27 ]} y DragonFly BSD .

StackGuard y ProPolice no pueden proteger contra desbordamientos en estructuras asignadas automáticamente que desbordan en punteros a funciones. ProPolice, al menos, reorganizará el orden de asignación para que dichas estructuras se asignen antes que los punteros a funciones. En PointGuard ^{[ 28 ]} se propuso un mecanismo independiente para la protección de punteros , disponible en Microsoft Windows ^{[ 29 ]} .

El conjunto de compiladores de Microsoft implementa la protección contra desbordamiento de búfer desde la versión 2003 a través del modificador de línea de comandos /GS , que está habilitado de forma predeterminada desde la versión 2005. ^{[ 30 ]} El uso de /GS- desactiva la protección.

La protección contra el desbordamiento de pila se puede activar mediante la bandera del compilador -qstackprotect. ^{[ 31 ]}

Clang admite las mismas -fstack-protectoropciones que GCC ^{[ 32 ]} y un sistema de "pila segura" más robusto ( -fsanitize=safe-stack ) con un impacto en el rendimiento igualmente bajo. ^{[ 33 ]} Clang también tiene tres detectores de desbordamiento de búfer, a saber, AddressSanitizer ( ), ^{[ 6 ]} UBSan ( ), ^{[ 34 ]} y el no oficial SafeCode (última actualización para LLVM 3.0). ^{[ 35 ]}-fsanitize=address-fsanitize=bounds

Estos sistemas presentan diferentes ventajas y desventajas en términos de penalización de rendimiento, sobrecarga de memoria y clases de errores detectados. La protección de pila es estándar en ciertos sistemas operativos, incluido OpenBSD . ^{[ 36 ]}

El compilador de C y C++ de Intel admite protección contra el desbordamiento de pila con opciones similares a las proporcionadas por GCC y Microsoft Visual Studio. ^{[ 37 ]}

Fail-Safe C ^{[ 7 ]} es un compilador ANSI C de código abierto con seguridad de memoria que realiza comprobaciones de límites basadas en punteros gordos y acceso a memoria orientado a objetos. ^{[ 38 ]}

Inventado por Mike Frantzen , StackGhost es una simple modificación de las rutinas de desbordamiento y llenado de la ventana de registros que dificulta enormemente la explotación de desbordamientos de búfer. Utiliza una característica de hardware única de la arquitectura SPARC de Sun Microsystems —desbordamiento y llenado de la ventana de registros diferido , en pila y dentro del marco— para detectar de forma transparente las modificaciones de los punteros de retorno (una forma común de que un exploit secuestre las rutas de ejecución), protegiendo automáticamente todas las aplicaciones sin necesidad de modificar sus archivos ejecutables o de código fuente. El impacto en el rendimiento es mínimo: menos del uno por ciento. Los problemas de gdb resultantes fueron resueltos por Mark Kettenis dos años después, lo que permitió habilitar la función. Tras este evento, el código de StackGhost se integró (y optimizó) en la versión SPARC del sistema operativo OpenBSD .