ESSS
1.0.0
ESSS ist ein statisches Analysetool, mit dem fehlende und falsche Fehlerprüfungen in C- und C ++ - Codebasen erfasst werden können. Das Tool leitet automatisch Fehlerspezifikationen für Funktionen ab, ohne dass ein priori -Wissen benötigt wird. Anschließend findet er Codepositionen, an denen Fehlerprüfungen entweder fehlen oder mit diesen Spezifikationen nicht in Einklang stehen.
Dieses Repository enthält den ESSS -Quellcode sowie die Skripte und Daten, um das Tool und Eesi auf den im Papier verwendeten Benchmarks auszuführen.
Die Artefakt-Bewertung VM enthält bereits das ESSS-Tool und das LLVM Toolchain vorgefertigt. Die verwendete LLVM -Version ist 14.0.6. Der Grund, warum wir den Build eher selbst als eine von Distro geplante Version ausführen, besteht darin, die reproduzierbare Ergebnisse der genauen Ergebnisse sicherzustellen, ohne potenziell interferierende distrospezifische Patches zu haben.
Das Tool wird bei jeder neueren Linux -Verteilung unterstützt. Wir haben bestätigt, dass es bei Ubuntu 22.04 mit Sicherheit funktioniert. Es sind keine speziellen Hardwareanforderungen erforderlich, um ESSS auszuführen, obwohl wir mindestens 8 Gib RAM empfehlen. Obwohl das Tool mit weniger laufen kann, kann es für den größten Benchmark bis zu 2 Gib RAM dauern, so dass weniger Speicher für andere Prozesse zurückbleiben.
Wenn Sie das ESSS -Tool und/oder die LLVM -Toolchain manuell erstellen möchten, befolgen Sie diese Anweisungen.
Die folgenden Abhängigkeiten sind erforderlich, um das ESSS -Tool zu erstellen:
$ cd /home/evaluation/ESSS/llvm
$ mkdir llvm-project
$ cd llvm-project
$ wget https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.6/clang-14.0.6.src.tar.xz
$ wget https://github.com/llvm/llvm-project/releases/download/llvmorg-14.0.6/llvm-14.0.6.src.tar.xz
$ tar xf llvm-14.0.6.src.tar.xz
$ tar xf clang-14.0.6.src.tar.xz
$ mv clang-14.0.6.src clang
$ mv llvm-14.0.6.src llvm
$ cd ..
$ ./build-llvm.sh$ cd /home/evaluation/ESSS/analyzer
$ make Dadurch wird das Analysator -Tool aufgebaut und die Binärdatei im Verzeichnis /home/evaluation/ESSS/analyzer/build/lib .
Wenn Sie das Tool auf Ihre eigenen Benchmarks anwenden, müssen Sie zuerst die Bitcode -Dateien generieren. Dazu sollten Sie WLLVM verwenden. Befolgen Sie die Installationsanweisungen auf der Seite Wllvm Readme.
Darüber hinaus verlassen wir uns auch auf Musl, um Spezifikationen von LIBC zu schließen. Dies ist zwar nicht ausschließlich erforderlich, damit das Tool funktioniert, dies erhöht jedoch die Genauigkeit der abgeleiteten Spezifikationen. Die im Papier verwendete Version war Musl 1.2.3, aber jede Version sollte funktionieren. Dies sind die Schritte, um Musl in eine Bitcode -Datei aufzubauen:
cd musl
mkdir prefix
export CC=wllvm
./configure --prefix= " $( realpath prefix ) "
make -j4
make install
extract-bc prefix/lib/libc.soUm ein Programm zur Verwendung mit unserem Tool zu kompilieren, sollten Sie die Build -Anweisungen des Programms befolgen, aber den WLLVM -Wrapper als Compiler verwenden. Dies führt zu Bitcode -Dateien, die von unserem Tool analysiert werden können. Im Idealfall übergeben Sie alle Bitcode-Dateien separat an unser Tool, da das gesamte Programm gleichzeitig angeben wird (was standardmäßig durch Extrakt-BC geschieht), ist langsamer zu verarbeiten als separate Dateien.
Das Tool kann direkt durch Ausführen von ./kanalyzer in /home/evaluation/ESSS/analyzer/build/lib ausgeführt werden. Die Argumente sind die Pfade zu den Bitcode -Dateien. Die Ausgabe ist an stdout geschrieben. Das Tool enthält auch einige optionale Argumente, die mit der Option --help aufgeführt werden können.
Um das Tool auszuführen, um Spezifikationen zu schließen und Fehler in einem Programm zu erkennen, können Sie den folgenden Befehl verwenden:
./kanalyzer /path/to/mysl/libc.so.bc /path/to/bitcode1.bc /path/to/bitcode2.bc ...Die Ausgabe wird in STDOut geschrieben, dies umfasst die abgeleiteten Spezifikationen und die Fehler.
Das Tool unterstützt Konfigurationsoptionen, die mit den Befehlszeilenargumenten festgelegt werden können.
Die wichtigsten Konfigurationsoptionen sind:
--missing-ct : Der Schwellenwert für fehlende Schecks. Es werden nur Berichte mit einer Punktzahl gemeldet. Der Standardwert beträgt 0,725.--incorrect-ct : Der Schwellenwert für falsche Spezifikationen. Es werden nur Berichte mit einer Punktzahl gemeldet. Der Standardwert beträgt 0,725.Weitere nützliche Optionen sind:
--refine-vsa : Dies ermöglicht die Übersicht zwischen dem Fehlerwertsatz und den möglichen Konstantrückgabewerten der Funktion, um die Genauigkeit der Fehlerspezifikationen zu erhöhen. Standardmäßig true.--st : Assoziationsanalysevertrauen zwischen [0, 1]. Je sicherer der Verein sein muss. Standardeinstellung auf 0,925.--interval-ct : Vertrauensschwelle zwischen [0, 1]. Je höher die Fehlerintervalle sein sollten.-c <number> : Legt die Anzahl der Threads auf <number> fest. Nicht gründlich auf andere Werte als 1 getestet.Es gibt auch einige Debugging -Optionen:
--print-random-non-void-function-samples <number> : Wie viele zufällige Nicht-Void-Funktionsnamen zum Drucken nützlich für Abtastfunktionen zur Berechnung eines Rückrufs. Standardmäßig 0.--ssc : Drucken die erkannten Fehler separat aus. Standardmäßig falsch. Wir geben im example ein minimales Beispiel. Es gibt einen einfachen Spielzeugcode in example/example.c example/build_and_run.sh Beim Laufen sollten Sie die folgende Ausgabe erhalten:
Function error return intervals (3, pre-libc-pruning 3):
Function: func {return index 0}
[0, 0]
Function: generate_error {return index 0}
[-2147483648, -1] U [1, 2147483647]
Function: malloc {return index 0}
[0, 0]
Das Repository ist wie folgt strukturiert. Von Crix angepasste Dateien sind als solche markiert.
? ESSS
│ ├── ? analyzer [the ESSS tool source code]
│ │ │ ├── ? Makefile [adapted from Crix]
│ │ │ └── ? src
│ │ │ │ ├── ? ...
│ │ │ │ └── ? src
│ │ │ │ │ ├── ? Analyzer.{cc, h} [Entry point of the application, adapted from Crix]
│ │ │ │ │ ├── ? CallGraph.{cc, h} [MLTA component from Crix]
│ │ │ │ │ ├── ? ClOptForward.h [Forward declarations of command line options]
│ │ │ │ │ ├── ? Common.{cc, h} [Common utility functions, adapted from Crix]
│ │ │ │ │ ├── ? DataFlowAnalysis.{cc, h} [Dataflow analysis helpers]
│ │ │ │ │ ├── ? DebugHelpers.{cc, h} [Debugging helpers]
│ │ │ │ │ ├── ? EHBlockDetector.{cc, h} [Specification inference component]
│ │ │ │ │ ├── ? ErrorCheckViolationFinder.{cc, h} [Bug detection component]
│ │ │ │ │ ├── ? FunctionErrorReturnIntervals.{cc, h} [Data structure file]
│ │ │ │ │ ├── ? FunctionVSA.{cc, h} [Value set analysis of return values component]
│ │ │ │ │ ├── ? Helpers.{cc, h} [Common utility functions]
│ │ │ │ │ ├── ? Interval.{cc, h} [Interval data structure]
│ │ │ │ │ ├── ? Lazy.h [Lazy execution utility class]
│ │ │ │ │ ├── ? MLTA.{cc, h} [MLTA component from Crix]
│ │ │ │ │ └── ? PathSpan.h [Data structure to store (parts of) paths]
│ └── ? evaluation [Scripts and data to run the tool on the benchmarks]
│ │ ├── ? benchmark-instructions [Instructions to compile each benchmark into bitcode files]
│ │ ├── ? ...
│ │ ├── ? eesi-<program>-output [Our EESI output for <program>]
│ │ ├── ? eesi-<program>-precision [Random sample from EESI's output for <program> for precision calculation]
│ │ ├── ? run-eesi-<program>.sh [Runs EESI for <program> (e.g. openssl)]
│ │ ├── ? my-<program>-output [Our ESSS output for <program>]
│ │ ├── ? run-my-<program>.sh [Runs ESSS for <program> (e.g. openssl)]
│ │ ├── ? <program>-bugs [Bug categorisations for <program> (e.g. openssl)]
│ │ ├── ? <program>-recall-sample [Random sample from error-returning functions in <program> for recall calculation]
│ │ ├── ? <program>-precision-ground-truth [Ground truth for precision evaluation for ESSS]
│ │ ├── ? <program>-random-functions-for-precision-my-tool [Random sample from ESSS's output for <program> for precision calculation]
│ │ ├── ? compute_my_stats.py [Computes stats for ESSS for a program]
│ │ └── ? compute_eesi_stats.py [Computes stats for EESI for a program]
Insbesondere wird die Spezifikationsinferenz in EHBLOCKDETECTECTECTECTCC und die fehlerhafte Erkennung von FehlerCheckviolationFinder.cc implementiert.
Die Anweisungen zum Ausführen jedes Benchmarks finden Sie im Verzeichnis evaluation/benchmark-instructions . Um eines der Benchmarks auszuführen, führen Sie das entsprechende Skript im evaluation (wie in der obigen Übersicht über die Repository -Struktur beschrieben) aus.
compute_my_stats.py : Dieses Skript berechnet die Präzisions-, Rückruf- und F1 -Punktzahl des ESSS -Tools für einen bestimmten Benchmark.compute_eesi_stats.py : Dieses Skript berechnet die Präzisions-, Rückruf- und F1 -Punktzahl des EESI -Tools für einen bestimmten Benchmark.run-eesi-<program>.sh : Dieses Skript führt das EESI-Tool auf dem gegebenen Benchmark aus.run-my-<program>.sh : Dieses Skript führt das ESSS-Tool auf dem gegebenen Benchmark aus. Um die Bewertung zu erleichtern, haben wir für jeden Benchmark ein Run -Skript zur Ausführung des Tools bereitgestellt. Diese können in /home/evaluation/ESSS/evaluation gefunden werden:
run-my-openssl.shrun-my-openssh.shrun-my-php.shrun-my-zlib.shrun-my-libpng.shrun-my-freetype.shrun-my-libwebp.sh Das Bewertungsartefakt wird als VirtualBox VM -Bild auf Zenodo bereitgestellt. Um das VM-Bild zu erstellen, starteten wir von einer Ubuntu 22.04 LTS (X86-64) Installation. Wir können dann das in vm/build-vm.sh bereitgestellte Skript verwenden, um alles zu installieren und einzurichten, was für die Bewertung erforderlich ist.
Dieses Tool basiert auf dem Crix -Tool der University of Minnesota. Insbesondere verwenden wir die MLTA -Komponente von Crix wieder. ESSS wird unter derselben Lizenz verteilt.
Link zur Seite Usenix Paper Publication: https://www.usenix.org/conference/Usenixsecurity24/presentation/dossche
Link zur endgültigen Veröffentlichung PDF: https://www.usenix.org/system/files/usenixsecurity24-dossche.pdf
Link zum endgültigen Artefaktanhang PDF (verfügbare, funktionale, reproduzierte Abzeichen): https://www.usenix.org/system/files/usenixsecurity24-Appendix-dossche.pdf
@inproceedings {dossche2024inferenceoferrorspecifications,
author = {Niels Dossche and Bart Coppens},
title = {Inference of Error Specifications and Bug Detection Using Structural Similarities},
booktitle = {33rd USENIX Security Symposium (USENIX Security 24)},
year = {2024},
isbn = {978-1-939133-44-1},
address = {Philadelphia, PA},
pages = {1885--1902},
url = {https://www.usenix.org/conference/usenixsecurity24/presentation/dossche},
publisher = {USENIX Association},
month = aug
}
