Valutazione delle tecniche di integrazione del flusso di controllo a livello binario

La corruzione della memoria è un problema serio nel software che può portare ad attacchi sui sistemi informatici. Uno dei metodi di attacco più comuni si chiama dirottamento del flusso di controllo, dove un attaccante prende il controllo dell'esecuzione del programma. Per combattere questi attacchi, si utilizza una tecnica chiamata Integrità del flusso di controllo (CFI). La CFI garantisce che un programma segua solo i percorsi di esecuzione validi come previsto dai suoi sviluppatori. Ci sono due tipi principali di CFI: CFI a livello sorgente, che funziona con il codice originale, e CFI a livello binario, che opera su programmi compilati.

Questo articolo si concentra sulla valutazione di quanto siano efficaci le tecniche di CFI a livello binario rispetto a quelle a livello sorgente. Si discute di come possiamo valutare queste tecniche e le sfide coinvolte nel farlo.

#Contesto

#Integrità del Flusso di Controllo

La CFI è progettata per proteggere i programmi dal deviare dai loro percorsi previsti. Quando un programma è in esecuzione, dovrebbe saltare solo a posizionamenti target specifici definiti dal programmatore. Se un attaccante prova a reindirizzare il flusso del programma verso una posizione non voluta, la CFI dovrebbe bloccarlo.

La CFI si basa sull'analisi del programma per creare un grafo di flusso di controllo (CFG), che mostra i percorsi di esecuzione validi. Durante l'esecuzione, la CFI controlla che l'esecuzione del programma segua questo grafo.

#Importanza della Sicurezza della Memoria

I programmi scritti in lingue come C e C++ spesso hanno vulnerabilità che possono essere sfruttate a causa di problemi di sicurezza della memoria. Tecniche come Stack Canaries, Randomizzazione del Layout degli Indirizzi (ASLR) e Prevenzione dell'Esecuzione dei Dati (DEP) sono in atto per aiutare a proteggersi da queste vulnerabilità. Tuttavia, gli attaccanti trovano comunque modi per aggirare queste difese, soprattutto usando metodi come gli Attacchi di riutilizzo del codice (CRA).

I CRA riguardano l’utilizzo di codice esistente in un programma per eseguire azioni malevole invece di eseguire nuovo codice. Per combattere questo, la CFI sta diventando un meccanismo di difesa cruciale, specialmente a livello binario, dove il codice sorgente non è disponibile per l'analisi.

#CFI a Livello Binario vs. CFI a Livello Sorgente

La CFI a livello binario è necessaria per i programmi distribuiti senza il loro codice sorgente. Tuttavia, recuperare accuratamente le informazioni del programma dai binari è una sfida. Abbiamo bisogno di dettagli specifici, come il numero e i tipi degli argomenti delle funzioni, che potrebbero non essere disponibili dopo la compilazione. Questa mancanza di informazioni precise può portare a imprecisioni nella validità della CFI a livello binario.

In questo lavoro, sviluppiamo un Framework di Valutazione per confrontare l'efficacia di diverse tecniche di CFI a livello binario e vedere come si confrontano con quelle a livello sorgente.

#Il Nostro Framework

Abbiamo creato un framework modulare chiamato Binary-CFI per misurare l'efficacia di varie tecniche di CFI basate su tipi a livello binario. Il framework aiuta a raccogliere informazioni necessarie per l'analisi del programma sia da strumenti a livello sorgente che a livello binario.

#Metriche di Valutazione

Per valutare le tecniche di CFI a livello binario, abbiamo introdotto nuove metriche per determinare quanti target validi vengono raggiunti e quanti target errati vengono consentiti. Ci siamo concentrati sui veri positivi (target correttamente identificati), falsi positivi (target identificati erroneamente), veri negativi (target correttamente rifiutati) e falsi negativi (target corretti mancati).

Le nuove metriche ci aiutano a capire quanto bene le tecniche di CFI a livello binario si comportano rispetto alle loro controparti a livello sorgente.

#Metodologia

#Raccolta di Informazioni

Per valutare l'efficacia delle tecniche di CFI a livello binario, dovevamo raccogliere dati da entrambe le analisi a livello sorgente e a livello binario. Abbiamo usato il compilatore LLVM per raccogliere informazioni durante il processo di compilazione del codice sorgente. Per l'analisi a livello binario, abbiamo utilizzato lo strumento di reverse engineering IDA Pro per estrarre informazioni rilevanti del programma.

#Tecniche di CFI in Valutazione

Ci siamo concentrati su quattro diverse politiche di CFI a livello binario:

1. TypeArmor - Questa politica è la più permissiva, considerando solo il numero di argomenti senza guardare ai loro tipi.
2. IFCC - Questa politica considera il numero di argomenti e i loro tipi di base ignorando i tipi di puntatore.
3. MCFI - Una politica più rigorosa che distingue tra diversi tipi di puntatore e abbina i numeri e i tipi degli argomenti.
4. CFI - Questa politica considera argomenti e i loro tipi insieme ai tipi di ritorno basati su regole specifiche.

#Benchmark di Test

Abbiamo valutato il nostro framework utilizzando diversi benchmark, tra cui programmi della suite SPEC e grandi applicazioni del mondo reale come Nginx, Node.js e PostgreSQL. Queste applicazioni hanno fornito una buona miscela di scenari per valutare le prestazioni delle tecniche di CFI.

#Risultati

#Configurazioni dei Benchmark

Abbiamo impostato due configurazioni di benchmark per i test:

1. Scenario Ideale - Qui, includiamo simboli di debug per aiutare a guidare l'analisi.
2. Scenario Pratico - In questo caso, i simboli di debug sono stati rimossi, mettendo alla prova i framework di analisi binaria.

#Metriche di Prestazione

Dopo aver applicato le politiche di CFI a livello binario in entrambe le configurazioni, abbiamo confrontato le metriche per capire quanto fosse efficace ciascuna politica nell'identificare target validi e minimizzare i target errati.

#Osservazioni

1. TypeArmor è stata la politica più rilassata, consentendo il numero maggiore di target.
2. MCFI ha mostrato un approccio più rigoroso con un numero inferiore di target, indicando una selezione più attenta dei target validi.
3. Le tecniche di CFI a livello binario hanno avuto notevoli difficoltà rispetto a quelle a livello sorgente, soprattutto quando i simboli di debug erano assenti.

#Sfide nell'Analisi Binaria

La CFI a livello binario si basa fortemente sull'accuratezza delle informazioni recuperate dai binari. Sfortunatamente, come abbiamo visto nei nostri esperimenti, gli strumenti attuali spesso non riescono a recuperare informazioni precise a livello binario.

Ad esempio, rilevare i tipi degli argomenti delle funzioni e altri dati correlati può portare a tassi di errore elevati. L'accuratezza nel rilevamento del numero degli argomenti e dei tipi di ritorno è particolarmente problematica quando i simboli di debug sono stati rimossi.

#Implicazioni degli Errori

Le imprecisioni osservate evidenziano problemi significativi nelle prestazioni delle tecniche di CFI a livello binario. Se le informazioni utilizzate per prendere decisioni sul flusso di controllo valido sono errate, la politica di CFI potrebbe consentire percorsi non sicuri o rifiutare quelli sicuri, portando potenzialmente a vulnerabilità di sicurezza.

#Conclusione

In questo lavoro, abbiamo sviluppato un framework per valutare l'efficacia delle tecniche di CFI a livello binario. Sebbene la CFI fornisca una protezione essenziale contro gli attacchi di dirottamento del flusso di controllo, è fondamentale capire le sfumature e le limitazioni delle implementazioni a livello binario.

Le nostre scoperte indicano che, sebbene ci siano approcci promettenti per migliorare la CFI a livello binario, rimangono sfide sostanziali. L'imprecisione nel recupero delle informazioni dai binari continua a minare i benefici di sicurezza che la CFI mira a fornire.

#Lavoro Futuro

Andando avanti, è necessario ulteriore ricerca per migliorare l'accuratezza degli strumenti di analisi binaria ed esplorare modi per migliorare le politiche di CFI. Affrontando queste sfide, possiamo proteggere meglio i programmi dagli attacchi di dirottamento del flusso di controllo e migliorare la sicurezza complessiva del software.