Qual è il set più incisivo di opzioni per GCC che compila C / C ++?

Naviga le tue risposte
58

Quale serie di opzioni GCC offre la migliore protezione contro le vulnerabilità di corruzione della memoria come Buffer Overflow e Dangling Pointer? GCC fornisce qualsiasi tipo di mitigazione della catena ROP? Ci sono problemi di prestazioni o altri problemi che potrebbero impedire a questa opzione GCC di essere in un'applicazione mission-critical?

Sto osservando la guida di Debian Hardening così come GCC Mudflap . Ecco le seguenti configurazioni che sto 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)

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

Siamo più preoccupati di proteggere WebKit.

    
posta rook 24.11.2012 - 04:25
fonte

2 risposte

45

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

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

  • -Wconversion -Wsign-conversion
    Warn on unsign / sign conversion.

  • -Wformat-security < br> Avvisare gli usi delle funzioni di formattazione che rappresentano possibili problemi di sicurezza.

  • -Werror
    Trasforma tutti gli avvisi in errori.

  • -arch x86_64
    Compilate a 64-bit per sfruttare al massimo lo spazio degli indirizzi (importante per ASLR, più spazio di indirizzamento virtuale da scegliere quando layout randomizzato).

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

  • -fstack-protector-all -Wstack-protector --param ssp-buffer-size = 4
    La tua scelta di "-fstack-protector" non protegge tutte le funzioni (vedi commenti). Hai bisogno di -fstack-protector-all per garantire che le guardie vengano applicate a tutte le funzioni, anche se questo probabilmente incorre in una penalità legata alle prestazioni. Considera -fstack-protector-strong come una via di mezzo.
    Il flag -Wstack-protector fornisce avvisi per tutte le funzioni che non verranno protette.

  • -fstack-clash-protection
    Sconfigge una classe di attacchi chiamata stack clashing .

  • -pie -fPIE
    Per ASLR.

  • -ftrapv
    Genera trap per overflow con segno (attualmente ha rilevato errori in gcc e potrebbe 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 (rilocazione di sola lettura). Le opzioni relro & now specificato insieme è noto come "Full RELRO". È possibile specificare "RELRO parziale" omettendo il flag now .   RELRO contrassegna le varie sezioni di memoria ELF in sola lettura (ad esempio GOT ). < br>

Se si esegue la compilazione su Windows, si prega di Visual Studio invece di GCC, in quanto alcune protezioni per Windows (ad esempio SEHOP) non fanno parte di GCC, ma se si deve usare GCC:

  • -Wl, dynamicbase
    Indica al linker di utilizzare la protezione ASLR.
  • -Wl, nxcompat
    Indica al linker di utilizzare la protezione DEP.
risposta data 02.12.2012 - 16:30
fonte
4

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

    
risposta data 25.11.2012 - 12:07
fonte

Leggi altre domande sui tag

La rete locale deve essere compromessa prima che i dispositivi IoT siano accessibili? Requisiti minimi per la memorizzazione delle ultime 4 cifre del numero della carta di credito?