Zwei neue Schwachstellen im eBPF-Subsystem wurden identifiziert, die das Ausführen von Handlern innerhalb des Linux-Kernels in einer speziellen virtuellen Maschine mit JIT erlauben. Beide Schwachstellen ermöglichen es, eigenen Code mit Kernel-Rechten außerhalb der isolierten eBPF-VM auszuführen. Informationen zu den Problemen wurden vom Zero Day Initiative-Team veröffentlicht, das die Pwn2Own-Wettbewerbe durchführt. In diesem Jahr wurden dabei drei Angriffe auf Ubuntu Linux demonstriert, die unbekannte Schwachstellen verwendeten (ob die Schwachstellen im eBPF mit diesen Angriffen zusammenhängen, wurde nicht bekannt gegeben).
- CVE-2021-3490 — Die Schwachstelle resultiert aus dem Fehlen einer Überprüfung von Überläufen bei der Ausführung von bitweisen AND-, OR- und XOR-Operationen in der eBPF ALU32. Ein Angreifer kann diesen Fehler ausnutzen, um Daten außerhalb der Grenzen des zugewiesenen Puffers zu lesen und zu schreiben. Das Problem bei der XOR-Operation tritt ab der Kernel-Version 5.7-rc1 auf, während AND und OR ab der Version 5.10-rc1 betroffen sind.
- CVE-2021-3489 — Die Schwachstelle entsteht durch einen Fehler in der Implementierung des Ringpuffers und hängt damit zusammen, dass die Funktion bpf_ringbuf_reserve nicht überprüfte, ob die Größe des zugewiesenen Speicherbereichs kleiner sein könnte als die tatsächliche Größe des Ringpuffers. Das Problem tritt ab der Version 5.8-rc1 auf.
Den Status der Behebung der Schwachstellen in den Distributionen kann man auf diesen Seiten verfolgen: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Die Behebungen sind auch in Form von Patches verfügbar (CVE-2021-3489, CVE-2021-3490). Die Möglichkeit, das Problem auszunutzen, hängt von der Verfügbarkeit des eBPF-Systemaufrufs für den Benutzer ab. Beispielsweise benötigt ein Benutzer in der Standardkonfiguration von RHEL, um die Schwachstelle auszunutzen, Rechte von CAP_SYS_ADMIN.
Besonders erwähnenswert ist eine weitere Schwachstelle im Linux-Kernel — CVE-2021-32606, die es einem lokalen Benutzer ermöglicht, seine Privilegien auf Root-Niveau zu erhöhen. Das Problem tritt ab Kernel-Version 5.11 auf und wird durch einen Race Condition in der Implementierung des CAN ISOTP-Protokolls verursacht, die es ermöglicht, die Bindungsparameter des Sockets aufgrund fehlender geeigneter Sperren in der Funktion isotp_setsockopt() beim Verarbeiten des Flags CAN_ISOTP_SF_BROADCAST zu ändern.
Nach dem Schließen des ISOTP-Sockets bleibt die Bindung an den Empfängersocket bestehen, der weiterhin die mit dem Socket verbundenen Strukturen nutzen kann, nachdem der zugehörige Speicher freigegeben wurde (use-after-free aufgrund des Zugriffs auf die bereits freigegebene isotp_sock-Struktur beim Aufruf von isotp_rcv()). Durch Datenmanipulationen kann der Zeiger auf die Funktion sk_error_report() überschrieben werden, wodurch Code auf Kernel-Ebene ausgeführt werden kann.
Quelle: opennet.ru
