it-swarm-eu.dev

Qual è la serie più complessa di opzioni per la compilazione di GCC in C / C ++?

Quale set di opzioni GCC offre la migliore protezione contro le vulnerabilità di corruzione della memoria come Buffer Overflow e Dangling Pointers? GCC offre qualche tipo di mitigazione della catena ROP? Ci sono problemi di prestazioni o altri problemi che impedirebbero a questa opzione GCC di trovarsi in un'applicazione mission-critical?

Sto guardando Debian Hardening Guide e GCC Mudflap . Ecco le seguenti configurazioni che sto prendendo in considerazione:

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

Ci sono miglioramenti che possono essere apportati a questo set di opzioni?

Siamo molto preoccupati di proteggere WebKit.

64
rook

Non codifico per gcc, quindi spero che qualcun altro possa aggiungerlo o correggermi. Lo modificherò con le risposte. Alcuni di questi non funzioneranno in tutte le circostanze.

  • - Wall -Wextra
    Attiva tutti gli avvisi per garantire che il codice sottostante sia sicuro.

  • - Wconversion -Wsign-conversion
    Avvisa sulla conversione unsign/sign.

  • - Wformat-sicurezza
    Avvisa degli usi delle funzioni di formato che rappresentano possibili problemi di sicurezza.

  • - Werror
    Trasforma tutti gli avvisi in errori.

  • - Arch x86_64
    Compilare per 64 bit per sfruttare al massimo lo spazio degli indirizzi (importante per ASLR; più spazio degli indirizzi virtuali tra cui scegliere durante il layout randomizzato).

  • - mmitigate-ROP
    Tentativo di compilare il codice senza indirizzi di ritorno involontari, rendendo ROP solo un po 'più difficile.

  • - mindirect-branch = thunk -mfunction-return = thunk
    Abilita retpoline (ritorno trampolini) per mitigare alcune varianti dello Spettro V2. Il secondo flag è necessario su Skylake + a causa del fatto che il buffer di destinazione del ramo è vulnerabile.

  • - fstack-protector-all -Wstack-protector --param ssp-buffer-size = 4
    La scelta di "-fstack-protector" non protegge tutte le funzioni (vedi commenti). Hai bisogno -fstack-protector-all per garantire che le protezioni siano applicate a tutte le funzioni, sebbene ciò comporti probabilmente una penalità per le prestazioni. Prendere in considerazione -fstack-protector-strong come via di mezzo.
    Il -Wstack-protector flag qui fornisce avvisi per tutte le funzioni che non saranno protette.

  • - fstack-scontro-protezione
    Sconfigge una classe di attacchi chiamata stack clashing .

  • - pie -fPIE
    Richiesto per ottenere tutti i vantaggi di sicurezza di ASLR.

  • - ftrapv
    Genera trappole per overflow firmato (attualmente corretto in gcc e può interferire con UBSAN).

  • - D_FORTIFY_SOURCE = 2
    Controlli di overflow del buffer. Vedi anche differenza tra = 2 e = 1 .

  • - Wl, -z, relro, -z, ora
    RELRO (trasferimento di sola lettura). Le opzioni relro & now specificate insieme sono note come "RELRO completo". È possibile specificare "RELRO parziale" omettendo il flag now. RELRO contrassegna immediatamente varie sezioni della memoria ELF (ad es. GOT ).

  • - Wl, -z, noexecstack
    Stack non eseguibile. Questa opzione contrassegna lo stack non eseguibile, probabilmente incompatibile con molto codice ma fornisce molta sicurezza contro ogni possibile esecuzione del codice. ( https://www.win.tue.nl/~aeb/linux/hh/protection.html )
  • - fvtable-verificare = [STD | PreInit | none]
    Verifica puntatore Vtable. Consente la verifica in fase di esecuzione, per ogni chiamata virtuale, che il puntatore vtable attraverso il quale viene effettuata la chiamata è valido per il tipo di oggetto e non è stato danneggiato o sovrascritto. Se viene rilevato un puntatore vtable non valido in fase di esecuzione, viene segnalato un errore e l'esecuzione del programma viene immediatamente interrotta. ( https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html =)
  • - FCF-Protezione = [completo | ramo | ritorno | none]
    Abilita la strumentazione del codice dei trasferimenti del flusso di controllo per aumentare la sicurezza del programma controllando che gli indirizzi target delle istruzioni di trasferimento del flusso di controllo (come chiamata di funzione indiretta, ritorno di funzione, salto indiretto) siano validi. Disponibile solo su x86 (_64) con CET di Intel. ( https://gcc.gnu.org/onlinedocs/gcc/Instrumentation- Options.html )

Se stai compilando su Windows, per favore Visual Studio invece di GCC, poiché alcune protezioni per Windows (es. SEHOP) non fanno parte di GCC, ma se devi usare GCC:

  • - Wl, dynamicbase
    Di 'al linker di usare la protezione ASLR.
  • - Wl, nxcompat
    Di 'al linker di usare la protezione DEP.
53
0xdabbad00

Queste sono buone opzioni, ma è necessario prestare attenzione al proprio codice sorgente. Assicurati di usare la funzione sicura quando gestisci gli input dell'utente, filtrali e quando usi qualcosa come strncpy (), cerca di non lasciare molto spazio per prevenire determinati attacchi. Il sistema operativo stesso fornisce sicurezza, ad esempio DEP (NX), ASLR e canarini per proteggere lo stack, ma non puoi fare affidamento su di essi per tutto il tempo. Quindi, sì, sopra è il mio suggerimento. Spero che ti aiuti un po 'e che tu possa anche usare gli strumenti di controllo del codice sorgente. In bocca al lupo!

4
3ntr0py