s a n d s i f t e r

: il fuzzer per processori x86

Panoramica

Il sandsifter esegue audit dei processori x86 per istruzioni nascoste e bug hardware, generando sistematicamente codice macchina per esplorare il set di istruzioni del processore e monitorando l'esecuzione per anomalie. Sandsifter ha scoperto istruzioni segrete del processore di ogni grande produttore; bug software ubiquitari in disassemblatori, assemblatori ed emulatori; difetti in hypervisor aziendali; e bug hardware sia benigni che critici per la sicurezza nei chip x86.

Con la moltitudine di processori x86 esistenti, l'obiettivo dello strumento è consentire agli utenti di controllare i propri sistemi per istruzioni nascoste e bug.

Per eseguire un audit di base sul tuo processore:

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

demo_sandsifter

Il computer viene scansionato sistematicamente per rilevare istruzioni anomale. Nella parte superiore, puoi vedere le istruzioni che il sandsifter sta attualmente testando sul processore. Nella parte inferiore, il sandsifter segnala le anomalie trovate.

La ricerca richiederà da poche ore a pochi giorni, a seconda della velocità e complessità del processore. Quando è completa, riassumi i risultati:

./summarize.py data/log

demo_summarizer

Tipicamente, verranno trovate diverse milioni di istruzioni non documentate sul processore, ma queste generalmente rientrano in un piccolo numero di gruppi diversi. Dopo aver raggruppato le anomalie, lo strumento di riepilogo tenta di assegnare ogni istruzione a una categoria di problema:

Bug software (ad esempio, un bug nel tuo hypervisor o disassemblatore),
Bug hardware (un bug nella tua CPU), o
Istruzione non documentata (un'istruzione che esiste nel processore, ma non è riconosciuta dal produttore)

Premi 'Q' per uscire e ottenere un riepilogo testuale della scansione del sistema:

I risultati di una scansione possono talvolta essere difficili da classificare automaticamente dagli strumenti e potrebbero richiedere un'analisi manuale. Per assistenza nell'analisi dei risultati, sentiti libero di inviare il file ./data/log a [email protected]. Nessuna informazione personale, oltre al modello del processore e alla revisione (da /proc/cpuinfo), è inclusa in questo log.

Risultati

La scansione con il sandsifter ha rivelato funzionalità del processore non documentate in dozzine di categorie di opcode, difetti in hypervisor aziendali, bug in quasi tutti i principali strumenti di disassemblaggio ed emulazione, e bug hardware critici che aprono vulnerabilità di sicurezza nel processore stesso.

I dettagli dei risultati si trovano nel whitepaper del progetto.

(TODO: enumerazione dettagliata dei risultati qui)

Compilazione

Sandsifter richiede prima l'installazione del disassemblatore Capstone: http://www.capstone-engine.org/. Capstone può essere tipicamente installato con:

sudo apt-get install libcapstone3 libcapstone-dev
sudo pip install capstone

Sandsifter può essere compilato con:

make

e poi eseguito con

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

Flag

I flag vengono passati al sifter con --flag, e all'injector con -- -f.

Esempio:

sudo ./sifter.py --unk --dis --len --sync --tick -- -P1 -t

Flag del sifter:

--len
	cerca differenze di lunghezza in tutte le istruzioni (istruzioni eseguite
	diversamente da quanto previsto dal disassemblatore, o non esistenti
	quando il disassemblatore se le aspettava)

--dis
	cerca differenze di lunghezza in istruzioni valide (istruzioni eseguite
	diversamente da quanto previsto dal disassemblatore)

--unk
	cerca istruzioni sconosciute (istruzioni che il disassemblatore non
	conosce ma vengono eseguite con successo)

--ill
	l'inverso di --unk, cerca disassemblaggi non validi (istruzioni che non
	vengono eseguite con successo ma che il disassemblatore riconosce)

--tick
	scrive periodicamente l'istruzione corrente su disco

--save
	salva l'avanzamento della ricerca all'uscita

--resume
	riprende la ricerca dall'ultimo stato salvato

--sync
	scrive i risultati della ricerca su disco man mano che vengono trovati

--low-mem
	non memorizza i risultati in memoria

Flag dell'injector:

-b
	modalità: forza bruta

-r
	modalità: fuzzing randomizzato

-t
	modalità: fuzzing a tunnel

-d
	modalità: fuzzing diretto esternamente

-R
	modalità output raw

-T
	modalità output testo

-x
	scrive progresso periodico su stderr

-0
	consenti dereferenziazione nulla (richiede sudo)

-D
	consenti prefissi duplicati

-N
	nessun supporto per bit NX

-s seed
	nella ricerca random, valore del seed

-B brute_depth
	nella ricerca brute, profondità massima di ricerca

-P max_prefix
	numero massimo di prefissi da cercare

-i instruction
	istruzione da cui iniziare la ricerca (inclusiva)

-e instruction
	istruzione a cui terminare la ricerca (esclusiva)

-c core
	core su cui eseguire la ricerca

-X blacklist
	blacklist dell'istruzione specificata

-j jobs
	numero di job simultanei da eseguire

-l range_bytes
	numero di byte base dell'istruzione in ogni sottintervallo

Tasti

m: Modalità - cambia la modalità di ricerca (forza bruta, random o tunnel) per il sifter

q: Esci - esci dal sifter

p: Pausa - metti in pausa o riprendi la ricerca

Algoritmi

La scansione supporta quattro diversi algoritmi di ricerca, che possono essere impostati dalla riga di comando o ciclati tramite tasti rapidi.

La ricerca random genera istruzioni casuali da testare; generalmente produce risultati rapidamente, ma non è in grado di trovare istruzioni nascoste e bug complessi.
La ricerca a forza bruta prova le istruzioni in modo incrementale, fino a una lunghezza specificata dall'utente; in quasi tutte le situazioni, ha prestazioni peggiori della ricerca random.
La ricerca guidata o basata su mutazione è progettata per creare nuove, istruzioni sempre più complesse tramite algoritmi genetici; sebbene promettente, questo approccio non è mai stato completamente realizzato ed è lasciato come stub per ricerche future.
Il tunneling è l'approccio descritto nella presentazione e nel white paper, e in quasi tutti i casi offre il miglior compromesso tra completezza e velocità.

Suggerimenti

sudo

Per ottenere i migliori risultati, lo strumento dovrebbe essere eseguito come utente root. Ciò è necessario affinché il processo possa mappare in memoria una pagina all'indirizzo 0, che richiede permessi di root. Questa pagina impedisce a molte istruzioni di causare segmentation fault sugli accessi alla memoria, consentendo un'analisi dei fault più accurata.
Prefissi

La limitazione principale per la profondità di una ricerca di istruzioni è il numero di byte di prefisso da esplorare, con ogni byte di prefisso aggiuntivo che aumenta lo spazio di ricerca di circa un fattore 10. Limita i byte di prefisso con il flag -P.
Colori

L'interfaccia del sifter è progettata per un terminale a 256 colori. Sebbene i dettagli varino molto a seconda del terminale, ciò può essere approssimativamente ottenuto con:
```
export TERM='xterm-256color'
```
GUI

L'interfaccia presuppone che il terminale abbia almeno una certa dimensione; se l'interfaccia non viene renderizzata correttamente, prova ad aumentare le dimensioni del terminale; ciò può spesso essere ottenuto riducendo la dimensione del font del terminale.

In alcuni casi, potrebbe essere desiderabile o necessario eseguire lo strumento senza l'interfaccia grafica. Questo può essere fatto eseguendo direttamente l'injector:
```
sudo ./injector -P1 -t -0
```
Per filtrare i risultati di un'invocazione diretta dell'injector, si può usare grep. Ad esempio,
```
sudo ./injector -P1 -r -0 | grep '\.r' | grep -v sigill
```
cerca istruzioni per le quali il processore e il disassemblatore hanno discordato sulla lunghezza dell'istruzione (grep '.r'), ma l'istruzione è stata eseguita con successo (grep -v sigill).
Fuzzing mirato

In molti casi, è utile indirizzare il fuzzer verso un obiettivo specifico. Ad esempio, se sospetti che un emulatore abbia difetti riguardo ai prefissi 'lock' ripetuti (0xf0), puoi indirizzare il fuzzer a cercare in questa regione dello spazio delle istruzioni con i flag -i e -e:
```
sudo ./sifter.py --unk --dis --len --sync --tick -- -t -i f0f0 -e f0f1 -D -P15
```

Riferimenti

Una discussione delle tecniche e dei risultati si trova nella presentazione del Black Hat.
I dettagli tecnici sono descritti nel whitepaper.
Le slide della presentazione Black Hat sono qui.

Autore

sandsifter è un progetto di ricerca di Christopher Domas (@xoreaxeaxeax).

sandsifter

Più Popolari