© HONGQI ZHANG, 123RF
Eine Komponente im Berkeley Packet Filter, die eigentlich Bytecode überprüfen soll, macht selber gravierende Fehler und gefährdet so die Sicherheit.
Der Berkeley Packet Filter (BPF) wurde ursprünglich 1992 als so genannte Special Purpose Virtual Machine entwickelt, um Datenpakete im Netzwerk zu filtern, ohne sie ineffizient ständig vom Kernel- zum Userspace kopieren zu müssen. Stattdessen sollte eine In-Kernel-Virtual-Maschine die Untersuchung an Ort und Stelle vornehmen.
Dafür implementierten die Entwickler den Berkeley-Filter als Interpreter in Maschinensprache für die Register-basierte BPF-Virtual-Maschine. Seither wurde er ständig erweitert und ist nun eine universelle VM, die Anknüpfungspunkte (Hooks) im gesamten Kernel hat.
Dieser Extended BPF (eBPF) ist sehr mächtig und kann nahezu beliebigen Programm-Bytecode im Kernel sicher ausführen. Die meiste Anwendung findet der BPF in Netzwerk-Tracing- und Security-Subsystemen des Kernels. So verwendet »tcpdump« beispielsweise den BPF, um Netzwerkdaten zu filtern.
Filter programmieren
Die eigentlichen Bytecode-Programme lädt der »bpf()«-Syscall. Ursprünglich musste der Anwender sie manuell als Assembler-Code schreiben und dann via »bpf_asm« in BPF-Bytecode übersetzen. Neuerdings unterstützt der LLVM Clang Compiler nun ein eBPF-Backend, das C-Code direkt in Bytecode übersetzt. Hierzu kann der Entwickler einfach die »-march=bpf«-Option verwenden.
Der Kernel enthält hierfür schon verschiedene Beispielprogramme in dem »samples/bpf«-Verzeichnis. Um das Schreiben von eBPF-Programmen zu vereinfachen, bietet der Kernel auch eine Bibliothek (»libbpf«) an, die nützliche Helper-Funktionen bereitstellt.
In der BPF-Kernel-Implementierung fanden Securityexperten nun drei verschiedene Sicherheitslücken. Alle drei Schwachstellen treten im Verfier-Code des BFP auf (»kernel/bpf/verifier.c«). Der ist dafür verantwortlich, den vom User Space bereitgestellten Bytecode zu überprüfen, bevor er im Kernel ausgeführt wird.
Damit sollen ungewollte Abstürze und Sicherheitsrisiken minimiert werden. Auch garantiert der Verifier, dass der Programmcode keine Schleifen enthält, die den Kernel ausbremsen könnten. Diese Kontrollen übernimmt eine Depth-First-Suche im Program-Control-Flow-Graphen.
Lücken im Detail
Die erste Sicherheitslücke hängt damit zusammen, dass der Verifier bei der Programmausführung unerreichbare Bytecode-Teile nicht korrekt inspiziert. Ein Angreifer kann dies ausnutzen, um Denial-of-Service-Attacken über den Just-in-Time-Compiler (JIT) auszuführen.
Diese Situation tritt auf, wenn der Verifier in einem Register eine Runtime-Konstante vorfindet und sie mit einer anderen Konstante vergleichen soll. Dann kontrolliert er nicht auszuführende Programmzweige nicht, worüber sich wiederum der JIT beschweren kann, was der Angreifer für seine Attacke nutzt. Anfällig hierfür sind die Kernelversionen bis 4.14.8.
Ein zweites Problem im Verifier tritt beim Auswerten von Stackframe-Zeigern auf. Dadurch darf ein Angreifer Befehle mit höheren Rechten ausführen. Er nutzt diese Schwachstelle aus, indem er ein Programm schreibt, das Out-of-Bound-Zeiger durch den Bytecode erzeugt. Damit kann er dann den Programmablauf nach seinen Wünschen ändern. Anfällig hierfür sind die 4.9er Kernelversionen bis 4.9.71.
Der dritte Fehler entsteht, weil der Verifier-Code keine Speicherzeiger-Leaks entdeckt. Das Problem besteht darin, dass die Vergleichsfunktion »states_equal()« nicht korrekt funktioniert, wenn sie der Code mit einem Zeigerdatentyp und dem »UNKNOWN_VALUE«-Datentyp aufruft. Durch diesen Fehler kann ein Angreifer sensible Adressinformationen ausspähen und auch unberechtigt an sensitive Informationen gelangen. Anfällig für dieses Problem sind die Kernelversionen bis 4.14.8.
