web-dev-qa-db-fra.com

Quel est l'ensemble d'options le plus renforcé pour la compilation GCC C / C ++?

Quel ensemble d'options GCC offre la meilleure protection contre les vulnérabilités de corruption de mémoire telles que les débordements de tampon et les pointeurs pendants? GCC fournit-il un type d'atténuation de la chaîne ROP? Y a-t-il des problèmes de performances ou d'autres problèmes qui empêcheraient cette option GCC d'être sur une application critique?

Je regarde le Debian Hardening Guide ainsi que GCC Mudflap . Voici les configurations suivantes que j'envisage:

-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)

Y a-t-il des améliorations à apporter à cet ensemble d'options?

Nous souhaitons surtout protéger WebKit.

buffer-overflowgccc++
64
rook

Je ne code pas pour gcc, donc j'espère que quelqu'un d'autre peut ajouter à cela, ou me corriger. Je vais le modifier avec des réponses. Certains d'entre eux ne fonctionneront pas dans toutes les circonstances.

  • - Mur -Wextra
    Activez tous les avertissements pour garantir la sécurité du code sous-jacent.

  • - Wconversion -Wsign-conversion
    Avertir de la conversion de signe/signe.

  • - Wformat-security
    Avertir des utilisations des fonctions de format qui représentent des problèmes de sécurité possibles.

  • - Erreur
    Transforme tous les avertissements en erreurs.

  • - Arch x86_64
    Compilez pour 64 bits pour profiter au maximum de l'espace d'adressage (important pour ASLR; plus d'espace d'adressage virtuel à choisir lors de la randomisation de la disposition).

  • - mmitigate-rop
    Essayez de compiler du code sans adresses de retour involontaires, ce qui rend ROP un peu plus difficile.

  • - mindirect-branch = thunk -mfunction-return = thunk
    Permet à retpoline (retour des trampolines) d'atténuer certaines variantes de Spectre V2. Le deuxième drapeau est nécessaire sur Skylake + en raison du fait que le tampon cible de la branche est vulnérable.

  • - fstack-protector-all -Wstack-protector --param ssp-buffer-size = 4
    Votre choix de "-fstack-protector" ne protège pas toutes les fonctions (voir commentaires). Vous avez besoin -fstack-protector-all pour garantir que les protections sont appliquées à toutes les fonctions, mais cela entraînera probablement une baisse de performance. Considérer -fstack-protector-strong comme terrain d'entente.
    Le -Wstack-protector flag ici donne des avertissements pour toutes les fonctions qui ne seront pas protégées.

  • - fstack-clash-protection
    Vainc une classe d'attaques appelée affrontement de pile .

  • - tarte -fPIE
    Requis pour obtenir tous les avantages de sécurité de l'ASLR.

  • - ftrapv
    Génère des interruptions pour le débordement signé (actuellement buggé dans gcc, et peut interférer avec UBSAN).

  • - D_FORTIFY_SOURCE = 2
    Vérifications de dépassement de tampon. Voir aussi différence entre = 2 et = 1 .

  • - Wl, -z, relro, -z, maintenant
    RELRO (relocalisation en lecture seule). Les options relro & now spécifiées ensemble sont appelées "RELRO complet". Vous pouvez spécifier "RELRO partielle" en omettant l'indicateur now. RELRO marque les différentes sections de mémoire ELF en lecture seule (par exemple GOT ).

  • - Wl, -z, noexecstack
    Pile non exécutable. Cette option marque la pile non exécutable, probablement incompatible avec beaucoup de code mais offre une grande sécurité contre toute exécution de code possible. ( https://www.win.tue.nl/~aeb/linux/hh/protection.html )
  • - fvtable-verify = [std | preinit | none]
    Vérification du pointeur Vtable. Il permet de vérifier au moment de l'exécution, pour chaque appel virtuel, que le pointeur vtable via lequel l'appel est effectué est valide pour le type de l'objet et n'a pas été corrompu ou écrasé. Si un pointeur vtable non valide est détecté au moment de l'exécution, une erreur est signalée et l'exécution du programme est immédiatement arrêtée. ( https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html =)
  • - fcf-protection = [full | branch | return | none]
    Activez l'instrumentation de code des transferts de flux de contrôle pour augmenter la sécurité du programme en vérifiant que les adresses cibles des instructions de transfert de flux de contrôle (telles que l'appel de fonction indirecte, le retour de fonction, le saut indirect) sont valides. Disponible uniquement sur x86 (_64) avec le CET d'Intel. ( https://gcc.gnu.org/onlinedocs/gcc/Instrumentation- Options.html )

Si vous compilez sous Windows, veuillez Visual Studio au lieu de GCC, car certaines protections pour Windows (ex. SEHOP) ne font pas partie de GCC, mais si vous devez utiliser GCC:

  • - Wl, base dynamique
    Dites à l'éditeur de liens d'utiliser la protection ASLR.
  • - Wl, nxcompat
    Dites à l'éditeur de liens d'utiliser la protection DEP.
53
0xdabbad00

Ce sont de bonnes options, mais vous devez faire attention à votre propre code source. Assurez-vous d'utiliser une fonction sécurisée lorsque vous traitez des entrées utilisateur, filtrez-les et lorsque vous utilisez quelque chose comme strncpy (), essayez de ne pas laisser beaucoup d'espace pour empêcher certaines attaques. Le système d'exploitation lui-même fournit la sécurité, c'est-à-dire le DEP (NX), l'ASLR et les canaris pour protéger la pile, mais vous ne pouvez pas compter sur eux tout le temps. Donc, oui, ci-dessus est ma suggestion. J'espère que cela vous aide un peu et que vous pouvez également utiliser des outils d'audit de code source. Bonne chance!

4
3ntr0py