trailofbits/polytrackerUno strumento di instrumentazione basato su LLVM per il taint tracking universale, l'analisi dei flussi di dati e il tracing.
PolyTracker è uno strumento originariamente creato per l'Automated Lexical Annotation and Navigation of Parsers, un retroacronimo ideato esclusivamente allo scopo di riferirsi ad esso come The ALAN Parsers Project. Tuttavia, si è evoluto in uno strumento di uso generale per eseguire in modo efficiente l'analisi del flusso di dati e del flusso di controllo dei programmi. PolyTracker è un pass LLVM che strumenta i programmi per tracciare quali byte di un file di input vengono elaborati da quali funzioni. Produce un database contenente le informazioni sul flusso di dati, oltre a una traccia di runtime. PolyTracker fornisce anche una libreria Python per interagire con e analizzare il suo output, nonché una REPL Python interattiva.
PolyTracker può essere usato in combinazione con PolyFile per determinare automaticamente lo scopo semantico delle funzioni in un parser. Dispone inoltre di una funzionalità sperimentale in grado di generare una grammatica libera dal contesto che rappresenta il linguaggio accettato da un parser.
A differenza delle alternative di strumentazione dinamica come , PolyTracker impone un overhead prestazionale trascurabile per quasi tutti gli input ed è in grado di tracciare ogni byte di input contemporaneamente. PolyTracker è nato come fork del DataFlowSanitizer di LLVM e trae molta ispirazione dall' . Tuttavia, a differenza del sistema Angora, PolyTracker è in grado di tracciare l'intera di un taint. Nel febbraio 2021, il DataFlowSanitizer di LLVM ha aggiunto una nuova funzionalità per tracciare la provenienza del taint chiamata . Tuttavia, può tracciare al massimo 16 taint contemporaneamente, mentre PolyTracker può tracciarne fino a 2-1.
Questo README funge da guida generale all'uso per installare PolyTracker e compilare/strumentare binari. Per interagire o estendere PolyTracker a livello programmatico tramite la sua API Python, nonché per interagire con le tracce di runtime prodotte dal codice strumentato, consulta la documentazione Python.
PolyTracker è controllato tramite uno script Python chiamato polytracker. Puoi
installarlo eseguendo
pip3 install polytracker
PolyTracker richiede un ambiente di sistema molto particolare per funzionare, quindi quasi tutti
gli utenti probabilmente lo eseguiranno in un ambiente containerizzato. Fortunatamente,
polytracker rende tutto semplice. Tutto ciò che devi fare è avere docker installato,
poi esegui:
polytracker docker pull
e
polytracker docker run
Quest'ultimo comando monterà la directory di lavoro corrente nel container Docker di PolyTracker e ti consentirà di compilare ed eseguire programmi strumentati.
Lo script di controllo polytracker — che puoi eseguire sia dal sistema host
sia dall'interno del container Docker — dispone di una varietà di comandi, sia per
strumentare programmi sia per analizzare gli artefatti risultanti. Ad
esempio, puoi esplorare i flussi di dati nell'esecuzione, ricostruire il
grafo del flusso di controllo del programma strumentato e persino estrarre una grammatica
libera dal contesto che corrisponde agli input accettati dal programma. Puoi esplorare questi
comandi eseguendo
polytracker --help
Lo script polytracker è anche una REPL, se eseguito senza argomenti da riga di comando:
$ polytracker
PolyTracker (4.0.0)
https://github.com/trailofbits/polytracker
Type "help" or "commands"
>>> commands
PolyTracker include anche un comando build. Questo comando consente all'utente di
eseguire qualsiasi comando di build in un ambiente strumentato Blight.
Verrà prodotto un file blight_journal.jsonl che
registra tutti i comandi eseguiti durante la build. Se hai un target C/C++, puoi
strumentarlo invocando polytracker build e passando il tuo comando di build:
polytracker build gcc -g -o my_binary my_source.c
Per strumentare un target di build, usa il comando instrument-targets. Per impostazione predefinita
il comando userà un blight_journal.jsonl nella tua directory di lavoro
corrente per creare una versione strumentata del tuo target di build. Il
target di build strumentato verrà compilato usando gli stessi flag del target di build
originale.
polytracker instrument-targets my_binary
build supporta anche programmi più complessi che usano un sistema di build come
autotiools o CMake:
polytracker build cmake .. -DCMAKE_BUILD_TYPE=Release
polytracker build ninja
# or
polytracker build ./configure
polytracker build make
Quindi esegui instrument-targets su qualsiasi target della build:
polytracker instrument-targets a.bin b.so
Quindi a.instrumented.bin e b.instrumented.so saranno le versioni
strumentate. Consulta i Dockerfile nella directory
examples
per esempi di come strumentare programmi reali.
Il software strumentato scriverà il suo output nel percorso specificato in
POLYDB, o in polytracker.tdag se omesso. Si tratta di un file binario su cui è possibile
operare eseguendo:
from polytracker import PolyTrackerTrace, taint_dag
trace = PolyTrackerTrace.load("polytracker.tdag")
tdfile = trace.tdfile
first_node = list(tdfile.nodes)[0]
print(f"First node affects control flow: {first_node.affects_control_flow}")
# Operate on all Range nodes
for index, node in enumerate(tdfile.nodes):
if isinstance(node, taint_dag.TDRangeNode):
print(f"Node {index}: first {node.first}, last {node.last}")
# Access taint forest
tdforest = trace.taint_forest
n1 = tdforest.get_node(1)
print(
f"Forest node {n1.label}. Parent labels: {n1.parent_labels}, "
f"source: {n1.source.path if n1.source is not None else None}, "
f"affects control flow: {n1.affected_control_flow}"
)
Puoi anche eseguire un binario strumentato direttamente dalla REPL:
$ polytracker
PolyTracker (4.0.0)
https://github.com/trailofbits/polytracker
Type "help" or "commands"
>>> trace = run_trace("path_to_binary", "path_to_input_file")
Questo eseguirà automaticamente il binario strumentato in un container Docker, se necessario.
⚠️ Se si esegue PolyTracker in Docker o in una VM: PolyTracker può essere molto lento se eseguito in un ambiente virtualizzato e se il file di input o, soprattutto, il database di output si trovano in una directory mappata o montata dal sistema host. Ciò è particolarmente vero quando si esegue PolyTracker in Docker da un host macOS. La soluzione è scrivere il database in un percorso all'interno del container/VM e poi copiarlo sul sistema host alla fine.
La documentazione dell'API Python è disponibile qui.
In fase di esecuzione, la strumentazione di PolyTracker cerca una serie di parametri di configurazione specificati tramite variabili d'ambiente. Ciò consente di modificare i parametri di strumentazione senza dover ricompilare il binario.
PolyTracker accetta parametri di configurazione sotto forma di variabili d'ambiente per evitare di ricompilare i programmi target. L'attuale insieme di variabili d'ambiente supportate da PolyTracker è:
POLYDB: A path to which to save the output database (default is polytracker.tdag)
WLLVM_ARTIFACT_STORE: Provides a path to an existing directory to store artifact/manifest for all build targets
POLYTRACKER_TAINT_ARGV: Set to '1' to use argv as a taint source.
POLYTRACKER_STDIN_SOURCE: Set to '1' to use stdin as a taint source.
POLYTRACKER_STDOUT_SINK: Set to '1' to use stdout as a taint sink.
POLYTRACKER_STDERR_SINK: Set to '1' to use stderr as a taint sink.
PolyTracker imposterà i suoi parametri di configurazione nel seguente ordine:
DFSan usa le liste ABI per determinare quali funzioni dovrebbe strumentare automaticamente, quali funzioni dovrebbe ignorare e quali wrapper di funzioni personalizzati esistono. Consulta la documentazione di dfsan per maggiori informazioni.
Tentare di compilare grandi progetti software può richiedere molto tempo, soprattutto quelli più vecchi/non supportati. È ancora più dispendioso in termini di tempo cercare di modificare il sistema di build in modo che supporti modifiche, come la strumentazione di dfsan/la nostra.
C'è uno script situato in polytracker/scripts che puoi eseguire su qualsiasi libreria
ELF e che restituirà un elenco di funzioni da ignorare. Lo usiamo quando non
vogliamo tracciare le informazioni che passano attraverso una libreria specifica come libpng, o
altri sottocomponenti di un programma. Il Dockerfile-listgen.demo esiste per compilare
comuni librerie open source in modo da poter creare questi elenchi.
Questo script è una versione leggermente modificata di quella di DataFlowSanitizer, che
si concentra sull'ignorare le librerie di sistema. Lo script originale si trova in
dfsan_rt.
Clona questo repository Git. Dalla root, puoi creare l'immagine Docker di base di PolyTracker:
pip3 install -e ".[dev]" && polytracker docker rebuild
oppure estrai semplicemente l'ultima versione precompilata da DockerHub:
docker pull trailofbits/polytracker:latest
Per una demo di PolyTracker eseguito sul parser MuPDF esegui questo comando:
docker build -t trailofbits/polytracker-demo-mupdf -f examples/pdf/Dockerfile-mupdf.demo .
mutool_track verrà compilato in /polytracker/the_klondike/mupdf/build/debug.
L'esecuzione di mutool_track produrrà polytracker.tdag, che contiene le
informazioni fornite dall'analisi del taint.
Per una demo di PolyTracker eseguito su Poppler utils versione 0.84.0 esegui questo comando:
docker build -t trailofbits/polytracker-demo-poppler -f examples/pdf/Dockerfile-poppler.demo .
Tutte le poppler utils si troveranno in
/polytracker/the_klondike/poppler-0.84.0/build/utils.
cd /polytracker/the_klondike/poppler-0.84.0/build/utils
./pdfinfo_track some_pdf.pdf
Supponiamo che tu voglia approfondire un po' di più l'estensione del codebase di PolyTracker o l'analisi delle tracce TDAG, e non vuoi alterare il tuo ambiente locale installando una versione di LLVM pesantemente personalizzata.
Se lavori su Ubuntu e parti da una base relativamente pulita 22.04 o 24.04, la Gist collegata descrive i passaggi per ottenere una versione passthrough funzionante del container di base di PolyTracker. Il container di base fornisce un ambiente di sviluppo con tutte le dipendenze in cui puoi lavorare direttamente, o che puoi estendere (come abbiamo fatto nei Dockerfile di esempio).
L'esecuzione dei test unitari sia Python che C++ dovrebbe essere effettuata all'interno del container Docker di PolyTracker.
I test unitari Catch2 in unittests/ si trovano in
/polytracker-build/unittests/src/taintdag/ all'interno del container. Esegui il binario di test
nel container Docker con
cd /polytracker-build/unittests/src/taintdag/ && ./tests-taintdag
I test unitari Python in tests/ richiedono programmi C++ di test locali che le
fixture di test strumenteranno. Esegui i test usando Pytest nella working
pytest tests
Oppure usa pytest per eseguire un singolo file di test con
pytest tests/test_foo.py
PolyTracker attualmente funziona solo su Linux, perché è l'unico sistema supportato dal DataFlow Santizer. Questa limitazione è dovuta semplicemente alla mancanza di supporto per la semantica delle system call di altri sistemi operativi, che potrebbe essere aggiunta in futuro. Ciò significa, tuttavia, che eseguire PolyTracker su un sistema non Linux richiederà l'installazione di Docker.
I taint non si propagheranno attraverso le librerie caricate dinamicamente a meno che quelle librerie non siano state compilate dal sorgente usando PolyTracker, o non ci sia un supporto specifico per le chiamate di libreria implementato in PolyTracker. Attualmente esiste supporto per propagare il taint attraverso la maggior parte delle chiamate della libreria standard C non strumentata. Per essere chiari, i programmi che usano funzioni non strumentate funzioneranno comunque normalmente, tuttavia le operazioni eseguite da chiamate di libreria non supportate non propagheranno il taint. Stiamo attualmente lavorando per aggiungere un supporto robusto per i programmi C++, ma al momento i migliori risultati si ottengono con i programmi C.
Se ci sono problemi con Docker, prova a eseguire una system prune e una build con
--no-cache sia per PolyTracker sia per qualunque demo tu stia cercando di eseguire.
Le prestazioni nel caso peggiore di PolyTracker si verificano quando un singolo byte in memoria viene contemporaneamente contaminato da un grande numero di byte di input del file sorgente. Ciò è più comune quando si strumentano algoritmi di compressione e crittografici con grandi dimensioni di blocco. Attualmente sono in fase di ricerca e sviluppo diverse mitigazioni per questo comportamento.
Ecco alcune delle cose disponibili pubblicamente che abbiamo fatto con PolyTracker. Se conosci qualcos'altro che vorresti vedere elencato qui, faccelo sapere!
mapping e cavities, più precisamente) per individuare una CVE e ne ha scritto sul blog di Trail of Bits.Questa ricerca è stata sviluppata da Trail of Bits con il finanziamento della Defense Advanced Research Projects Agency (DARPA) nell'ambito del programma SafeDocs come subappaltatore di Galois. È concessa in licenza ai sensi della licenza Apache 2.0. © 2019, Trail of Bits.
Contattaci usando [email protected].