IMChecker
1.0.0
Thu, IMCECECKER -Gruppe, kontaktieren Sie uns unter [email protected]
Bibliotheken bieten wiederverwendbare Funktionen über Anwendungsprogrammierschnittstellen (APIs) mit Nutzungsbeschränkungen wie Aufrufbedingungen oder Aufträgen. Einschränkungsverletzungen, dh Missverbrauch von API, führen üblicherweise zu Fehler und Sicherheitsproblemen. Obwohl Forscher in den letzten Jahrzehnten verschiedene API-Misuse-Detektoren entwickelt haben, zeigen jüngste Studien, dass API-Missbrauch in realen Projekten weit verbreitet ist. Die vorhandenen Ansätze leiden entweder unter dem spärlichen Einsatzproblem (dh Fehler, die selten auftreten) oder melden Fehlalarme aufgrund ungenauer Semantik. Um diese Einschränkungen zu überwinden, stellen wir Imchecker vor, um API-Misuse-Fehler effektiv zu erkennen. Der wichtigste Einblick hinter Imchecker ist eine von einer domänenspezifischen Sprache (DSL) angetriebene statische Analysetechnik zur Angabe von API-Nutzungsbeschränkungen. Durch das Studium der realen API-Misuse-Fehler schlagen wir IMSPEC DSL vor, das die meisten Arten von API-Verwendungsbeschränkungen abdeckt und eine einfache, aber präzise Spezifikation ermöglicht. Darüber hinaus entwerfen und implementieren wir Imchecker, um IMSPEC automatisch in die Überprüfung von Zielen zu untersuchen und eine statische Analyse -Engine zu verwenden, um potenzielle API -Missverhältnisse zu identifizieren und falsch positiv mit reichhaltigen Semantik zu prahlen. Wir haben IMCECKER für C-Programme instanziiert und es an weit verbreiteten Benchmarks und großflächigen realen Programmen bewertet.
Derzeit wurden 75 bisher unbekannte Fehler gefunden und 61 in Linux -Kernel, OpenSSL und Paketen in Ubuntu 16.04 bestätigt und behoben. Wir versuchen unser Bestes, um Imchecker auf weitere Programme anzuwenden. Wir laden die Details in evaluation_data/new_bugs hoch
Unser Forschungsmanuskript und unser Tool -Manuskript werden von ICSE'19 überprüft. Wir werden sie sobald nach Abschluss des Überprüfungsprozesses hochladen. (Nun, Sie können uns eine E -Mail senden, um nur nach akademischer Zweck auf sie zuzugreifen.)
Unser Tooldemdemonstrationsvideo ist bei der englischen Version verfügbar: https://youtu.be/ygdxeyoevim chinesische Version: https://www.youtube.com/watch?v=3zanegtwuto https://pan.baidu.com/s/1digq0r6wk5Shhmlottel
Verwendung unserer Tools bei Tools/Readme.md
Imchecker ist noch in der Entwicklung und enthält viele Fehler und Todo -Listen. Alle Fehler oder Feature -Anfragen können Sie uns gerne per E -Mail unter [email protected] oder offene Probleme senden.
Um besser zu verstehen, welche Art von API-Misuse-Fehler in realen C-Projekten auftritt und wie Entwickler sie in der Praxis beheben, haben wir die Versionsgeschichten von drei Jahren von drei Open-Source-Projekten und einem halben Jahr Linux-Kernel im Jahr 2017 manuell untersucht, wie in der folgenden Tabelle gezeigt. Diese Geschichten werden aufgrund der laufenden Entwicklung ausgewählt und weil sie häufig in verschiedenen Erkennung von Insekten erwähnt werden. Insgesamt haben wir ungefähr 13,57 m LOC und 51,1K -Commits untersucht.
| Projekt | Loc | Studierte Zeit | Total Commits | Fehlerbehebungen | API missbraucht |
|---|---|---|---|---|---|
| Locken | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| Gnutls | 35,8K | 20160101-20171231 | 2769 | 86 | 30 |
| OpenSSL | 454,2k | 20160101-20171231 | 6487 | 344 | 115 |
| Linux | 12,96 m | 20170701-20171231 | 39295 | 995 | 362 |
| Gesamt | 15,57 m | Zwei Jahre | 51.1k | 1560 | 509 |
Um den Lesern zu helfen, die Commit -Nachricht, die geänderten Dateien und die Patch -Dateien zu extrahieren, haben wir unser GitGrabber -Tool offen. Wir laden auch alle Commits im Zusammenhang mit API-Misuse-Fehler in den untersuchten Probanden zur weiteren Verwendung hoch.
Leser können sie im Ordner empirical_study finden. Bei Problemen auf Gitgrabber können Sie uns gerne kontaktieren!
Wir wählen in ihren neuesten Versionen einen weit verbreiteten Benchmark, IE, Juliet Test Suite V1.3 und zwei reale Programme aus: Linux Kernel-4.18-RC4, die am 2018-7-9 und OpenSSL-1-1-1-1-PRE8 am 2018-6-20 veröffentlicht wurden, um unseren Ansatz zu bewerten. Wir bewerten unseren Ansatz aus zwei Perspektiven.
Wir testen diese Fälle auch auf Apisan, ein Desinfizieren von API-Verwendungs-Erkennungsinstrumenten durch semantisches Kreuzprüfungen und Clang-Sa, ein statisches Open-Source-Tool.
Wir laden den API-Misuse-Benchmark und die Originalergebnisse unter evaluation_data hoch.
Die Hauptmotivation von Imchecker besteht darin, API-Misuse-Fehler in realen Programmen zu erkennen, nämlich festzustellen, ob Imchecker bisher unbekannte Fehler finden kann. Daher wenden wir Imchecker auf die neuesten Versionen von zwei bekannten Open-Source-Programmen an: Linux Kernel-4.18-RC4 und OpenSSL-1-1-1-1-PRE8 sowie Pakete in Ubuntu 16.04. Ziel -APIs werden aus den missbrauchten aus der empirischen Studie ausgewählt.
Bisher wurden 56 bisher unbekannte Fehler gefunden und 36 von Entwicklern bestätigt.
| Projekt | Fehler (wartende Antwort/bestätigt/behoben) |
|---|---|
| OpenSSL | 17 (0/5/12) |
| Linux | 30 (20.05.5) |
| DMA | 1 (0/0/1) |
| Exim | 2 (0/0/2) |
| Hexchat | 2 (1/1/0) |
| httping | 1 (0/1/0) |
| ipmitool | 1 (0/1/0) |
| Open-VM-Tools | 2 (0/0/2) |
| IRSSI | 2 (1/1/0) |
| Keepalive | 2 (0/0/2) |
| thc-ipv6 | 2 (0/0/2) |
| Freeradius-Server | 2 (0/0/2) |
| Trafficerver | 3 (00.03.0) |
| Tinc | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| rdesktop | 2 (00.02.0) |
| Proxytunnel | 2 (00.02.0) |
| Gesamt | 75 (16/29/32) |
Wir laden die Details in evaluation_data/new_bugs hoch
Es wurde gezeigt, dass Verhaltensspezifikationen, die API -Nutzungsbeschränkungen beschreiben, für Entwickler nützlich ist, APIs effektiv zu nutzen und das Problem der spärlichen Nutzung zu bewältigen, indem sie die Validierung der Verwendungen der Ziel -APIs sicherstellen. Zum Beispiel präsentiert Bodden Crysl, um die kognitive Kluft zwischen Kryptographieexperten und Entwicklern zu schließen. Aktuelle Spezifikationssprachen sind jedoch entweder für vollständige Programmeigenschaften wie BLAST, JML ausgelegt oder sind zu spezifisch, um auf eine generische API-Nutzerkennung wie SLIC angewendet zu werden. Wir stellen eine leichte domänenspezifische Sprache für API-Nutzungsbeschränkungen mit dem Namen IMSPEC ein. IMSPEC stellt gleichzeitig sicher, dass die Ziel -APIs auch mit wenigen Verwendungen validiert werden, und führt die Missbrauchserkennung. Eine Instanz von IMSPEC ist ein Muster, das mit einer Reihe von Einschränkungen gefüllt ist, um die API korrekt zu verwenden, und jeder Verstoß führt zu einem API-Misuse-Fehler.
Wir laden die IMSPEC -Instanzen in den IMPSEC -Ordner hoch und aktualisieren diesen Ordner inkrementell für weitere APIs. Außerdem kann IMSPEC zu einem anderen Zweck verwendet werden, z. B. Testfälle, Überprüfung usw. generieren. Darüber hinaus bieten wir einen GUI -IMSPEC -Schriftsteller bei Tools an.
Derzeit wird IMSPEC durch manuelles Schreiben erstellt. Wir stellen jedoch sicher, dass es automatisch aus Spezifikationsabbau -Techniken generiert werden kann. Wir versuchen unser Bestes, um Experimente durchzuführen und Parser zu implementieren, um die Ergebnisse von Mining -Tools in IMSPEC wie Apex zu übersetzen. Diese Tools können jedoch nicht alle Verwendungsbeschränkungen lösen. Wir möchten auch die Entwickler einladen, uns zu helfen, die gemäß dem Benutzerhandbuch generierten IMSPEC -Instanzen wie OpenSSL zu verfeinern.
Eine korrekte API-Nutzung muss eine Reihe von Nutzungsbeschränkungen erfüllen, dh Verstöße gegen die Einschränkungen können zu API-Misuse-Fehler führen. Imchecker erkennt diese Fehler automatisch im Quellcode mithilfe der Spezifikationen von IMSPEC. Um komplexe, reale Programme zu verarbeiten, müssen die zugrunde liegenden Mechanismen von Imchecker skalierbar sein, während die minimale Genauigkeit geopfert wird. Wir erfassen die Entwurfsdetails von Imchecker, einschließlich einer unterbrochenen symbolischen Ausführung mit statischen Analysetechniken, um den Analysekontext zu erstellen, Methoden zur Erkennung von API-Misuse-Fehler im Analysekontext und eine Methode, um falsch-positives Aspekten mit semantischen Informationen und Nutzungsstatistiken zu filtern.
Wir verwenden ein motivierendes Beispiel, um den Workflow von Imchecker zu veranschaulichen. Dies ist ein API-Misuse-Fehler in OpenSSL, der in CVE-2015-0288 angegeben ist. Die Überprüfung des fehlenden Fehlers Code von X509_get_pubkey() führte zu einem Nullzeiger-Dereference-Fehler in Zeile 4.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }Hier ist der Workflow von Imchecker:
Imchecker nimmt den Quellcode und die API -Nutzungsbeschränkungen als Eingabe ein und generiert Fehlerberichte mit konkreten Stellen und Gründen als Ausgabe. Erstens werden die API-Nutzungsbeschränkungen in einer leichten domänenspezifischen Sprache mit dem Namen IMSPEC geschrieben. Beispielsweise muss „der Rückgabewert von x509_get_pubkey () mit Null überprüft werden“ . Durch die Verwendung dieser Spezifikationen bestätigt IMCECECKER die Verwendung der Ziel -API, die das Problem der spärlichen Verwendung entlastet, direkt und leitet den Erkennungsprozess für Fehler. Dann erkennen wir API-Misuse-Fehler in drei Phasen. (1) In Phase-1 wird der Analysekontext durch Erstellen des Steuerflusspfads und das Erstellen von Programmpfadspuren für jede in den Spezifikationen definierte Ziel-API erstellt, indem eine unterbrochene symbolische Ausführung mit Punkt-zu-Reichweite, Bereich und pathemischer Analyse verwendet wird. In diesem Beispiel werden zwei Spuren, T1 und T2, generiert, wie in der Box oben mit Spuren von Programmpfad gezeigt. Auf diese Weise kann Imchecker den Verwendungskontext von X509_get_pubkey() , EVP_PKEY_free() und den dazwischen erfolgreich erfassen. (2) In Phase-2 setzt Imchecker die Spuren ein, um Verstöße gegen die Einschränkungen als potenzielle Fehler zu erkennen. Vorbeispielen werden zweiapi-Misuse-Instanzen von X509_get_pubkey() für fehlende Fehlercodeprüfungen gefunden, die als potenzielle Fehler gekennzeichnet sind. (3) In Phase-3 verbessert Imchecker die Erkennungsgenauigkeit, indem sie mehrere Nutzungsinstanzen und die semantischen Informationen nutzt. Anschließend wird der zweite Missbrauch für den Scheck in der X509_to_X509_REQ() unter Zeile-25 herausgefiltert.
Die Verwendung unseres Tools finden Sie hier: Tools/Readme.md
Während der Untersuchung der von Imchecker generierten Fehlerberichte finden wir einige interessante Fehler und sammeln nützliche Erfahrungen im Fehlerberichterstattungsprozess mit Open-Source-Entwicklern. Wir teilen unsere folgenden Erfahrungen.
Die Autoren bedanken sich bei den Entwicklern von Linux Kernel und OpenSL, um uns zu helfen, die IMSPEC zu verfeinern und Fehlerberichte zu bestätigen.
