CHC-based Automated Verification of WebAssembly Programs
Dieses Paper schlägt eine automatisierte statische Verifikationsmethode für eine Teilmenge von WebAssembly unter Verwendung von beschränkten Horn-Klauseln vor, welche indirekte Funktionsaufrufe durch typbasierte Filterung effektiv handhabt und große Panic-Handler mittels Zusammenfassung der Kontrollflussanalyse verwaltet.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich das Internet als eine riesige, geschäftige Stadt vor, in der jedes Gebäude eine Website ist. Jahrelang wurden diese Gebäude mit einem spezifischen, schweren Satz von Blaupausen gebaut, die sie zwar sicher, aber manchmal langsam in der Konstruktion machten. Dann kam WebAssembly, eine neue, super-effiziente Sprache. Es ist wie ein universelles, Hochgeschwindigkeits-Drohnen-System, das überall im Web fliegen kann und schwere Lasten an Code trägt, um Spiele, Werkzeuge und Apps direkt in Ihrem Browser auszuführen. Da diese Drohnen so schnell und leistungsstark sind, müssen wir sicherstellen, dass sie niemals in ein Gebäude krachen oder ihre Fracht am falschen Ort abwerfen. Das ist die Aufgabe der „Verifizierung“ – ein schicker Begriff für den mathematischen Beweis, dass ein Programm sicher ist, bevor es überhaupt ausgeführt wird.
Um dies zu erreichen, verwenden Informatiker oft ein „Satisfiability Solver“-Werkzeug (Erfüllbarkeitslösungs-Werkzeug). Stellen Sie sich diesen Solver wie einen super-intelligenten Detektiv vor, der Regeln analysieren kann und sofort sagen kann, ob ein Szenario möglich oder unmöglich ist. Wenn die Regeln besagen: „Die Drohne muss in der Luft sein“ und „Die Droste muss auf dem Boden sein“ und zwar gleichzeitig, weiß der Detektiv, dass dies ein Widerspruch ist und der Plan unsicher ist. Dieses Paper nimmt diesen Detektiv und lehrt ihn, die spezifischen, kniffligen Regeln von WebAssembly zu verstehen, insbesondere jene Teile, die andere Funktionen indirekt aufrufen und massive Fehlermeldungen verarbeiten.
Das Geheimnis des Gestaltwandelnden Aufrufs
Die Autoren, Akihisa Yagi, Ken Sakayori und Naoki Kobayashi von der Universität Tokio, standen vor einem schwierigen Rätsel. WebAssembly-Programme sind wie eine riesige Bibliothek, in der Bücher (Funktionen) dynamisch aus den Regalen gezogen werden können. Manchmal sagt der Code nicht „Öffne Buch A“, sondern stattdin: „Öffne das Buch im Regal Nummer 5“. Dies wird als indirekter Funktionsaufruf bezeichnet.
Das Problem ist: Wenn man versucht, jedes einzelne Buch in der Bibliothek zu prüfen, um zu sehen, was sich in Regal Nummer 5 befinden könnte, wird der Detektiv (der Solver) überfordert. Es ist, als würde man versuchen, jede einzelne mögliche Kombination von einer Million Schlössern zu prüfen, um den richtigen Schlüssel zu finden. Der naive Ansatz wäre, jede einzelne Möglichkeit aufzulisten, aber das erzeugt einen Berg an Papierkram, den kein Computer in einer angemessenen Zeit bewältigen kann.
Die Lösung der Autoren war, wie ein sehr strenger Bibliothekar zu agieren. Sie erkannten, dass WebAssembly eine Regel hat: Man kann ein Buch nur aus dem Regal ziehen, wenn es dem spezifischen Genre (Typ) entspricht, das man sucht. Anstatt also jedes Buch in der Bibliothek zu prüfen, schaut ihre Methode auf das „Genre“, das an der Aufrufstelle gefordert wird, und filtert alle Bücher heraus, die nicht passen. Dies schrumpft die Liste der Kandidaten drastisch und macht die Arbeit des Detektivs viel einfacher. Sie fügten noch einen zweiten Trick hinzu: Wenn die Bibliotheksregale verschlossen und unveränderlich sind (read-only), können sie im Voraus berechnen, welches Buch genau wo steht, wodurch ein komplexes Rätsel in eine einfache Liste von „Wenn dies, dann das“-Regeln verwandelt wird.
Der riesige Panik-Knopf
Die zweite Herausforderung war der „Panic Handler“ (Panik-Behandler). Stellen Sie sich ein Programm vor, das, wenn es einen Fehler macht, nicht einfach nur stoppt, sondern eine massive, 10.000 Schritte lange Rede darüber abhält, was genau schiefgelaufen ist – komplett mit Diagnosediagrammen und Fehlercodes –, bevor es schließlich aufgibt. In WebAssembly sind diese Panic Handler riesige Codeblöcke, die ausgelöst werden, wenn etwas schiefgeht.
Für den Sicherheitsprüfer sind diese massiven Reden eine Ablenkung. Das Einzige, was zählt, ist, dass das Programm schließlich sicher aufhört zu laufen (eine „unreachable“-Instruktion erreicht). Der lange, windelige Pfad des Erstellen der Fehlermeldung ändert nichts an der Tatsache, dass das Programm abstürzt. Wenn der Detektiv jedoch versucht, jeden einzelnen Schritt dieser 10.000-stufigen Rede nachzuverfolgen, gerät er ins Stocken.
Die Autoren führten eine „Summarization“-Technik (Zusammenfassungstechnik) ein. Sie erkannten: Wenn ein Codeblock lediglich dazu dient, zu einem Absturz zu führen, können sie den Mittelsmann abschneiden. Sie nutzten eine Kontrollflussanalyse, um diese langen, windeligen Pfade zu identifizieren und ersetzten sie durch eine einfache Abkürzung: „Wenn du diesen Raum betrittst, wirst du schließlich abstürzen.“ Es ist, als würde man einem Reiseführer sagen: „Überspringen Sie den 50-minütigen Geschichtsunterricht über die Lobby; sagen Sie uns einfach, dass der Ausgang blockiert ist.“ Dies hält die Verifizierung auf die kritischen Sicherheitsthemen konzentriert, ohne sich im Rauschen der Fehlermeldung zu verlieren.
Die Ergebnisse: Eine laufende Arbeit
Um ihre Ideen zu testen, baute das Team ein Prototyp-Werkzeug namens WASMVERIFIER. Sie fütterten es mit 90 verschiedenen Programmen, darunter einige, die in Rust und C geschrieben wurden, und baten es, deren Sicherheit zu beweisen.
Die Ergebnisse waren vielversprechend, aber nicht perfekt. Unter Verwendung von zwei verschiedenen Detektiv-Solvern (Z3 Spacer und Eldarica) konnte das Tool die Sicherheit von etwa 54 bis 56 Programmen erfolgreich verifizieren oder widerlegen. Es stieß jedoch bei etwa 20 bis 22 Programmen an eine Grenze, indem es entweder die Zeit (ein „Timeout“) oder den Speicher aufbrauchte. In etwa 11 bis 12 Fällen gab es einen „Fehlalarm“, indem das Tool annahm, ein Programm sei unsicher, obwohl es eigentlich in Ordnung war. Die Autoren erklären, dass diese Fehlalarme auftraten, weil ihr Tool einige nicht unterstützte Instruktionen durch einen „Crash“-Platzhalter ersetzen musste, was die Sicherheitsprüfung zu vorsichtig machte.
Das Paper legt nahe, dass dieser Ansatz zwar ein starker Schritt nach vorn für vollautomatisierte Sicherheitsprüfungen ist, aber noch kein Zauberstab ist. Die Autoren merken an, dass die Methode noch verfeinert werden muss, insbesondere in der Handhabung komplexer Bit-Operationen (Bit-Vektoren) und im Umgang mit Instruktionen, die sie noch nicht vollständig verstehen. Sie vermuten, dass die Methode korrekt (sound) und vollständig (complete) ist, haben aber den formellen mathematischen Beweis dafür noch nicht geschrieben, was diese Aufgabe für die Zukunft lässt.
Kurz gesagt zeigt das Paper, dass wir durch eine intelligentere Filterung indirekter Aufrufe und durch die Zusammenfassung der chaotischen Teile des Error-Handlings automatisierte Sicherheitsprüfungen für WebAssembly wesentlich praktikabler machen können. Es ist ein solides Fundament, aber der Detektiv benötigt noch mehr Training, um jeden Fall lösen zu können.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.