Protección contra desbordamiento de búfer

Terminator canaries use the observation that most buffer overflow attacks are based on certain string operations which end at string terminators. The reaction to this observation is that the canaries are built of null terminators, CR, LF, and FF. As a result, the attacker must write a null character before writing the return address to avoid altering the canary. This prevents attacks using strcpy() and other methods that return upon copying a null character, while the undesirable result is that the canary is known. Even with the protection, an attacker could potentially overwrite the canary with its known value and control information with mismatched values, thus passing the canary check code, which is executed soon before the specific processor's return-from-call instruction.

Random canaries are randomly generated, usually from an entropy-gathering daemon, in order to prevent an attacker from knowing their value. Usually, it is not logically possible or plausible to read the canary for exploiting; the canary is a secure value known only by those who need to know it—the buffer overflow protection code in this case.

Normally, a random canary is generated at program initialization, and stored in a global variable. This variable is usually padded by unmapped pages so that attempting to read it using any kinds of tricks that exploit bugs to read off RAM cause a segmentation fault, terminating the program. It may still be possible to read the canary if the attacker knows where it is or can get the program to read from the stack.

Random XOR canaries are random canaries that are XOR-scrambled using all or part of the control data. In this way, once the canary or the control data is clobbered, the canary value is wrong.

Random XOR canaries have the same vulnerabilities as random canaries, except that the "read from stack" method of getting the canary is a bit more complicated. The attacker must get the canary, the algorithm, and the control data in order to re-generate the original canary needed to spoof the protection.

In addition, random XOR canaries can protect against a certain type of attack involving overflowing a buffer in a structure into a pointer to change the pointer to point at a piece of control data. Because of the XOR encoding, the canary will be wrong if the control data or return value is changed. Because of the pointer, the control data or return value can be changed without overflowing over the canary.

Although these canaries protect the control data from being altered by clobbered pointers, they do not protect any other data or the pointers themselves. Function pointers especially are a problem here, as they can be overflowed into and can execute shellcode when called.

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 .