Im eBPF-Subsystem wurden zwei neue Schwachstellen identifiziert, die es Ihnen ermöglichen, Handler innerhalb des Linux-Kernels in einer speziellen virtuellen Maschine mit JIT auszuführen. Beide Schwachstellen ermöglichen die Ausführung Ihres Codes mit Kernel-Rechten außerhalb einer isolierten virtuellen eBPF-Maschine. Informationen zu den Problemen wurden vom Team der Zero Day Initiative veröffentlicht, das den Pwn2Own-Wettbewerb veranstaltet, bei dem in diesem Jahr drei Angriffe auf Ubuntu Linux demonstriert wurden, die bisher unbekannte Schwachstellen nutzten (ob die Schwachstellen in eBPF mit diesen Angriffen zusammenhängen, wird nicht berichtet). .
- CVE-2021-3490 – Die Sicherheitslücke wird durch eine fehlende 32-Bit-Out-of-Bounds-Prüfung bei der Durchführung bitweiser AND-, OR- und XOR-Operationen in eBPF ALU32 verursacht. Ein Angreifer kann diesen Fehler ausnutzen, um Daten außerhalb der Grenzen des zugewiesenen Puffers zu lesen und zu schreiben. Das Problem mit XOR-Operationen tritt ab Kernel-Version 5.7-rc1 und AND- und OR-Operationen ab Kernel-Version 5.10-rc1 auf.
- CVE-2021-3489 – Die Sicherheitslücke wird durch einen Fehler in der Implementierung des Ringpuffers verursacht und liegt daran, dass die Funktion bpf_ringbuf_reserve nicht die Möglichkeit geprüft hat, dass die Größe des zugewiesenen Speicherbereichs kleiner als die tatsächliche Größe sein könnte des Ringbuf. Das Problem tritt seit Release 5.8-rc1 auf.
Der Status von Patching-Schwachstellen in Distributionen kann auf diesen Seiten verfolgt werden: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch). Korrekturen sind auch als Patches verfügbar (CVE-2021-3489, CVE-2021-3490). Ob das Problem ausgenutzt werden kann, hängt davon ab, ob der eBPF-Systemaufruf für den Benutzer zugänglich ist. Beispielsweise erfordert die Ausnutzung der Schwachstelle in der Standardkonfiguration in RHEL, dass der Benutzer über CAP_SYS_ADMIN-Rechte verfügt.
Unabhängig davon können wir eine weitere Schwachstelle im Linux-Kernel feststellen – CVE-2021-32606, die es einem lokalen Benutzer ermöglicht, seine Berechtigungen auf die Root-Ebene zu erhöhen. Das Problem tritt seit Linux-Kernel 5.11 auf und wird durch eine Race-Bedingung in der Implementierung des CAN-ISOTP-Protokolls verursacht, die es ermöglicht, die Socket-Bindungsparameter zu ändern, da in der Funktion isotp_setsockopt() nicht die richtigen Sperren gesetzt wurden bei der Verarbeitung des Flags CAN_ISOTP_SF_BROADCAST.
Nachdem der ISOTP-Socket geschlossen wurde, bleibt die Bindung an den Empfänger-Socket bestehen, der die mit dem Socket verbundenen Strukturen weiterhin verwenden kann, nachdem der damit verbundene Speicher freigegeben wurde (Use-after-free aufgrund des Aufrufs von isotp_rcv() Zugriff auf eine bereits freigegebene isotp_sock-Struktur). Durch Datenmanipulation können Sie den Zeiger auf die Funktion sk_error_report() überschreiben und Ihren Code auf Kernelebene ausführen.
Source: opennet.ru