ucsb-seclab/dr_checkerDR.CHECKER : Uno strumento di rilevamento delle vulnerabilità Soundy per i driver del kernel Linux
Questo repository contiene tutti i sorgenti, inclusi gli script di setup. Ora con una UI straordinaria per visualizzare gli avvisi insieme ai file sorgente corrispondenti.
Ubuntu >= 14.04.5 LTS
16 Feb 2018:
Fare riferimento al documento Docker Usage per i dettagli su come utilizzare DR.CHECKER in un contenitore docker pre-costruito.
La nostra implementazione è basata su LLVM, in particolare LLVM 3.8. Abbiamo anche bisogno di strumenti come c2xml per analizzare gli header.
Prima, assicurati di avere cmake (usato dagli script di setup/build) e libxml (richiesto per c2xml):
sudo apt-get install cmake libxml2-dev
Successivamente, abbiamo creato un singolo script che scarica e compila tutti gli strumenti necessari.
cd helper_scripts
python setup_drchecker.py --help
usage: setup_drchecker.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]
optional arguments:
-h, --help show this help message and exit
-b TARGET_BRANCH Branch (i.e. version) of the LLVM to setup. Default:
release_38 e.g., release_38
-o OUTPUT_FOLDER Folder where everything needs to be setup.
Esempio:
python setup_drchecker.py -o drchecker_deps
Per completare il setup hai anche bisogno di modifiche alla variabile d'ambiente PATH locale. Lo script di setup ti darà le modifiche esatte da fare.
Questo dipende dal completamento con successo di Setup. Abbiamo un singolo script che compila tutto, prego.
cd llvm_analysis
./build.sh
Questo dipende dal completamento con successo di Build. Per eseguire DR.CHECKER sui driver del kernel, dobbiamo prima convertirli in bitcode llvm.
Prima, abbiamo bisogno di un kernel compilabile. Ciò significa che dovresti essere in grado di compilare il kernel usando il normale setup di build, ad esempio make.
Prima catturiamo l'output del comando make, da questo output estraiamo il comando di compilazione esatto.
make (o makeout.txt)Basta passare V=1 e reindirizzare l'output al file.
Esempio:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
NOTA: NON USARE PROCESSI MULTIPLI, ad esempio -j. Eseguire in modalità multi-processo rovinerà il file di output poiché più processi cercano di scrivere nel file di output.
Questo è tutto. DR.CHECKER si occuperà del resto.
Ci sono diversi passaggi per eseguire l'analisi di DR.CHECKER, tutti questi passaggi sono racchiusi in un singolo script helper_scripts/runner_scripts/run_all.py
Come eseguire:
python run_all.py --help
usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT] [-k KERNEL_SRC_DIR] [-skb] [-skl] [-skp] [-ske] [-ski] [-f SOUNDY_ANALYSIS_OUT]
optional arguments:
-h, --help show this help message and exit
-l LLVM_BC_OUT Destination directory where all the generated bitcode files should be stored.
-a CHIPSET_NUM Chipset number. Valid chipset numbers are:
1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
-m MAKEOUT Path to the makeout.txt file.
-g COMPILER_NAME Name of the compiler used in the makeout.txt, This is
needed to filter out compilation commands. Ex: aarch64-linux-android-gcc
-n ARCH_NUM Destination architecture, 32 bit (1) or 64 bit (2).
-o OUT Path to the out folder. This is the folder, which
could be used as output directory during compiling
some kernels. (Note: Not all kernels needs a separate out folder)
-k KERNEL_SRC_DIR Base directory of the kernel sources.
-skb Skip LLVM Build (default: not skipped).
-skl Skip Dr Linker (default: not skipped).
-skp Skip Parsing Headers (default: not skipped).
-ske Skip Entry point identification (default: not
skipped).
-ski Skip Soundy Analysis (default: not skipped).
-f SOUNDY_ANALYSIS_OUT Path to the output folder where the soundy analysis output should be stored.
Lo script compila, linka ed esegue DR.CHECKER su tutti i driver, quindi potrebbe richiedere tempo considerevole (45 min-90 min). Se vuoi eseguire DR.CHECKER manualmente su singoli driver, fai riferimento a standalone
Lo script sopra esegue le seguenti attività in modalità multiprocessore per utilizzare tutti i core della CPU:
Tutti i file bitcode generati verranno inseriti nella cartella fornita all'argomento -l.
Questo passaggio richiede tempo considerevole, a seconda del numero di core che hai.
Quindi, se hai già eseguito questo passaggio, puoi saltarlo passando -skb.
Questo esegue il linking, passa attraverso tutti i file bitcode e identifica i file bitcode correlati che devono essere linkati e li linka (usando llvm-link) in un file bitcode consolidato (che verrà archiviato insieme al file bitcode corrispondente).
Simile al passaggio precedente, puoi saltare questo passaggio passando -skl.
Questo passaggio cerca le dichiarazioni dei punti di ingresso nei file header e memorizza la loro configurazione nel file: hdr_file_config.txt nella directory di compilazione LLVM.
Per saltare: -skp
Questo passaggio identifica tutti i punti di ingresso in tutti i file bitcode consolidati dei driver.
L'output verrà memorizzato nel file: entry_point_out.txt nella directory di compilazione LLVM.
Esempio di contenuto nel file entry_point_out.txt:
FileRead:hidraw_read:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
FileWrite:hidraw_write:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
IOCTL:hidraw_ioctl:/home/drchecker/33.2.A.3.123/llvm_bc_out/drivers/hid/llvm_link_final/final_to_check.bc
Per saltare: -ske
Questo passaggio eseguirà DR.CHECKER su tutti i punti di ingresso nel file entry_point_out.txt. L'output per ogni punto di ingresso verrà memorizzato nella cartella fornita per l'opzione -f.
Per saltare: -ski
Ora mostreremo un esempio dal punto in cui hai i sorgenti del kernel fino al punto in cui ottieni gli avvisi di vulnerabilità.
Abbiamo caricato un kernel mediatek 33.2.A.3.123.tar.bz2. Prima scarica ed estrai il file sopra.
Supponiamo che tu abbia estratto il file sopra in una cartella chiamata: ~/mediatek_kernel
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# the following step may not be needed depending on the kernel
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# this following command copies all the compilation commands to makeout.txt
make V=1 -j8 O=out ARCH=arm64 > makeout.txt 2>&1
cd <repo_path>/helper_scripts/runner_scripts
python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -m ~/mediatek_kernel/kernel-3.18/makeout.txt -g aarch64-linux-android-gcc -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/dr_checker_out
Il comando sopra richiede un po' di tempo (30 min - 1 ora).
Prima di tutto, tutti i risultati dell'analisi saranno nella cartella: ~/mediatek_kernel/dr_checker_out (argomento fornito all'opzione -f), per ogni punto di ingresso verrà creato un file .json che contiene tutti gli avvisi in formato JSON. Questi file json contengono avvisi organizzati per contesti.
In secondo luogo, la cartella ~/mediatek_kernel/dr_checker_out/instr_warnings (relativamente all'argomento fornito all'opzione -f) contiene avvisi organizzati per posizione dell'istruzione.
Questi avvisi possono essere analizzati utilizzando il nostro Visualizer.
Infine, un riepilogo di tutti gli avvisi per ogni punto di ingresso organizzato per tipo verrà scritto nel file CSV di output: ~/mediatek_kernel/dr_checker_out/warnings_stats.csv (relativamente all'argomento fornito all'opzione -f).
-gPer fornire il valore per l'opzione -g devi conoscere il nome del binario *-gcc utilizzato per compilare il kernel.
Un modo semplice per saperlo sarebbe grep per gcc in makeout.txt e vedrai i comandi del compilatore dai quali puoi conoscere il nome del binario *-gcc.
Per il nostro esempio sopra, se fai grep gcc makeout.txt per la build di esempio, vedrai molte righe come quelle sotto:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d -nostdinc -isystem ...
Quindi, il valore per -g dovrebbe essere aarch64-linux-android-gcc.
Se il kernel da compilare è a 32 bit, molto probabilmente il binario sarà arm-eabi-gcc
-aA seconda del tipo di chipset, devi fornire il numero corrispondente.
-oQuesto è il percorso della cartella fornita all'opzione O= per il comando make durante la compilazione del kernel.
Non tutti i kernel necessitano di un percorso out separato. Puoi compilare il kernel senza fornire un'opzione O, nel qual caso NON dovresti fornire un valore per quell'opzione durante l'esecuzione di run_all.py.
Forniamo un'interfaccia web per visualizzare tutti gli avvisi. Fare riferimento a Visualization.
Puoi disabilitare uno o più controllori di vulnerabilità decommentando le righe #define DISABLE_* corrispondenti in BugDetectorDriver.cpp
A tuo piacimento, forniamo anche uno script per post-elaborare i risultati. Dai un'occhiata.
Divertiti!!