¿Cuál es el conjunto de opciones más sólido para que GCC compile C / C ++?

Navega tus respuestas
57

¿Qué conjunto de opciones de GCC proporciona la mejor protección contra las vulnerabilidades de corrupción de memoria, como los desbordamientos de búfer y los punteros colgantes? ¿GCC proporciona algún tipo de mitigación de la cadena ROP? ¿Existen problemas de rendimiento u otros problemas que impidan que esta opción de GCC esté en una aplicación de misión crítica?

Estoy viendo la Guía de Debian Hardening y también GCC Mudflap . Aquí están las siguientes configuraciones que estoy considerando: 

-D_FORTIFY_SOURCE=2
-fstack-protector --param ssp-buffer-size=4
-fPIE -pie
-Wl,-z,relro,-z,now (ld -z relro and ld -z now)

¿Se pueden realizar mejoras en este conjunto de opciones?

Estamos más preocupados por la protección de WebKit.

    
pregunta rook 24.11.2012 - 04:25
fuente

2 respuestas

43

No codifico para gcc, así que espero que alguien más pueda agregar algo a esto o corregirme. Lo editaré con respuestas. Algunos de estos no funcionarán para todas las circunstancias.

  • -Wall -Wextra
    Active todas las advertencias para asegurarse de que el código subyacente sea seguro.

  • -Conversión -Wsign-conversion
    Avisar sobre la conversión de unsign / sign.

  • -Wformat-security < br> Avisar sobre los usos de las funciones de formato que representan posibles problemas de seguridad.

  • -Werror
    Convierte todos los avisos en errores.

  • -arch x86_64
    Compile para que 64 bits aprovechen al máximo el espacio de direcciones (importante para ASLR; más espacio de direcciones virtuales para elegir cuando se aleatoriza el diseño).

  • -mmitigate-rop
    Intente compilar código sin direcciones de retorno no intencionadas, lo que hace que ROP sea un poco más difícil.

  • -fstack-protector-all -Wstack-protector --param ssp-buffer-size = 4 Su elección de "-fstack-protector" no protege todas las funciones (ver comentarios). Necesita -fstack-protector-all para garantizar que las guardas se apliquen a todas las funciones, aunque esto probablemente conlleve una penalización de rendimiento. Considere -fstack-protector-strong como un término medio.
    La marca -Wstack-protector aquí advierte sobre cualquier función que no se va a proteger.

  • -pie -fPIE
    Para ASLR.

  • -ftrapv
    Genera trampas para el desbordamiento firmado (actualmente bugged en gcc, y puede interferir con UBSAN).

  • -D_FORTIFY_SOURCE = 2 O2
    Verificaciones de desbordamiento de búfer. Ver también la diferencia entre = 2 y = 1 .

  • -Wl, -z, relro, -z, ahora
      RELRO (reubicación de sólo lectura). Las opciones relro & Los now especificados juntos se conocen como "RELRO completo". Puede especificar "PARCIAL RELRO" omitiendo el indicador now .   RELRO marca varias secciones de la memoria ELF de manera leída (por ejemplo, GOT ). br>

Si compila en Windows, Visual Studio en lugar de GCC, ya que algunas protecciones para Windows (por ejemplo, SEHOP) no son parte de GCC, pero si debe usar GCC:

  • -Wl, dynamicbase
    Indique al vinculador que use la protección ASLR.
  • -Wl, nxcompat
    Indique al vinculador que use la protección DEP.
respondido por el 0xdabbad00 02.12.2012 - 16:30
fuente
4

Esas son buenas opciones, pero debes prestar atención a tu propio código fuente. Asegúrese de usar la función segura cuando trate con las entradas del usuario, filtrelas y cuando use algo como strncpy (), intente no dar mucho espacio para evitar ciertos ataques. El propio sistema operativo proporciona seguridad, es decir, DEP (NX), ASLR y canarios para proteger la pila, pero no se puede confiar en ellos todo el tiempo. Entonces, sí, arriba es mi sugerencia. Espero que te ayude un poco y también puedas usar las herramientas de auditoría de código fuente. ¡Buena suerte!

    
respondido por el 3ntr0py 25.11.2012 - 12:07
fuente

Lea otras preguntas en las etiquetas

¿Por qué pasar el ID de sesión como parámetro url inseguro? ¿Es necesario hackear la red local primero para que los dispositivos de IoT sean accesibles?