ejecutar - Cómo desactivar la optimización del compilador gcc para habilitar el desbordamiento del búfer

gcc wikipedia

Question

Estoy trabajando en un problema de tarea que requiere deshabilitar la protección de optimización del compilador para que funcione. Estoy usando gcc 4.4.1 en Ubuntu Linux, pero no puedo entender qué banderas son las correctas. Me doy cuenta de que depende de la arquitectura: mi máquina funciona con un procesador Intel de 32 bits.

Gracias.

Answer 1

En las distribuciones más nuevas (a partir de 2016), parece que PIE está habilitada de manera predeterminada, por lo que deberá deshabilitarla explícitamente al compilar.

Aquí hay un pequeño resumen de comandos que pueden ser útiles cuando se juega localmente con ejercicios de desbordamiento de búfer en general:

Deshabilitar canario:

gcc vuln.c -o vuln_disable_canary -fno-stack-protector

Deshabilitar DEP:

gcc vuln.c -o vuln_disable_dep -z execstack

Deshabilitar pastel:

gcc vuln.c -o vuln_disable_pie -no-pie

Deshabilite todos los mecanismos de protección enumerados arriba (advertencia: para pruebas locales solamente):

gcc vuln.c -o vuln_disable_all -fno-stack-protector -z execstack -no-pie

Para máquinas de 32 bits, también deberá agregar el parámetro -m32 .

Answer 2

Ese es un buen problema. Para resolver ese problema, también deberá desactivar ASLR; de lo contrario, la dirección de g () será impredecible.

Deshabilitar ASLR:

sudo bash -c ''echo 0 > /proc/sys/kernel/randomize_va_space''

Desactivar canarios:

gcc overflow.c -o overflow -fno-stack-protector

Después de inhabilitar los canarios y ASLR, debería ser un ataque directo como los descritos en Smashing the Stack for Fun and Profit.

Aquí hay una lista de características de seguridad utilizadas en ubuntu: https://wiki.ubuntu.com/Security/Features No tiene que preocuparse por los bits NX, la dirección de g () siempre estará en una región ejecutable de la memoria porque está dentro del segmento de memoria TEXTO. Los bits NX solo entran en juego si intenta ejecutar shellcode en la pila o en el montón, que no es necesario para esta tarea.

¡Ahora ve y destruye ese EIP !

Answer 3

No citaré toda la página, pero todo el manual sobre optimización está disponible aquí: http://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Optimize-Options.html#Optimize-Options

A partir de sus sonidos, al menos -O0 , el valor predeterminado, y:

-fmudflap -fmudflapth -fmudflapir

Para los frontales que lo soportan (C y C ++), instrumente todas las operaciones arriesgadas de eliminación de referencias de puntero / matriz, algunas funciones de cadena / pila de biblioteca estándar y algunas otras construcciones asociadas con pruebas de rango / validez. Los módulos así instrumentados deberían ser inmunes a los desbordamientos del búfer, al uso no válido del montón y a otras clases de errores de programación C / C ++. La instrumentación se basa en una biblioteca de tiempo de ejecución independiente (libmudflap), que se vinculará a un programa si -fmudflap se da en tiempo de enlace. El comportamiento en tiempo de ejecución del programa instrumentado está controlado por la variable de entorno MUDFLAP_OPTIONS. Ver env MUDFLAP_OPTIONS = -help a.out para sus opciones.

Answer 4

Pruebe la -fno-stack-protector .

Answer 5

Sé que es un hilo viejo, pero quiero señalar que no es necesario deshabilitar ASLR para realizar un desbordamiento de búfer. Aunque ASLR está habilitado (kernel_randomize_va_space = 2), no tendrá efecto a menos que el ejecutable compilado sea PIE, de modo que a menos que haya compilado su archivo con el indicador -fPIC -pie, ASLR no tendrá efecto.

Creo que basta con deshabilitar los canarios con -fno-stack-protector. Si desea verificar si ASLR está funcionando o no (se debe establecer el código de posición independiente), use: hardening-check nombre_ejecutable

Answer 6

Urm, todas las respuestas hasta ahora han sido incorrectas porque la respuesta de Rook es correcta.

Entrando:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Seguido por:

gcc -fno-stack-protector -z execstack -o bug bug.c

Deshabilita ASLR, SSP / Propolice y Ubuntu''s NoneXec (que se colocó en 9.10, y es bastante fácil de ver, vea la técnica mprotect(2) para asignar páginas como ejecutable y jmp) debería ayudar un poco, sin embargo estas "características de seguridad" son no significa infalible. Sin el indicador `-z execstack '', las páginas tienen marcas de pila no ejecutables.