Zwei neue Schwachstellen im eBPF-Subsystem wurden entdeckt, das es ermöglicht, Handler innerhalb des Linux-Kernels in einer speziellen virtuellen Maschine mit JIT auszuführen. Beide Schwachstellen ermöglichen es, eigenen Code mit Kernel-Rechten auszuführen, außerhalb der isolierten eBPF-virtuellen Maschine. Informationen zu den Problemen wurden vom Zero Day Initiative-Team veröffentlicht, das die Pwn2Own-Wettbewerbe veranstaltet, bei denen in diesem Jahr drei Angriffe auf Ubuntu Linux demonstriert wurden, die zuvor unbekannte Schwachstellen nutzten (ob die Schwachstellen im eBPF mit diesen Angriffen in Verbindung stehen, wird nicht mitgeteilt).
- CVE-2021-3490 — Die Schwachstelle wird durch fehlende Überprüfungen des Überlaufs von 32-Bit-Werten bei der Ausführung von bitwise AND-, OR- und XOR-Operationen in der 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 der XOR-Operation tritt ab Kernel-Version 5.7-rc1 und bei AND und OR ab der Veröffentlichung 5.10-rc1 auf.
- CVE-2021-3489 – Diese Schwachstelle resultiert aus einem 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 Speichers kleiner sein könnte als die tatsächliche Größe des Ringpuffers. Das Problem tritt seit der Version 5.8-rc1 auf.
Der Status von Sicherheitskorrekturen in den Distributionen kann auf den folgenden Seiten verfolgt werden: Ubuntu, Debian, RHEL, Fedora, SUSE, Arch. Korrekturen sind auch als Patches verfügbar (CVE-2021-3489, CVE-2021-3490). Die Möglichkeit zur Ausnutzung des Problems hängt von der Verfügbarkeit des Systemaufrufs eBPF für den Benutzer ab. Beispielsweise ist in der Standardeinstellung in RHEL für die Ausnutzung der Schwachstelle das Vorhandensein von CAP_SYS_ADMIN-Rechten erforderlich.
Eine weitere Schwachstelle im Linux-Kernel – CVE-2021-32606 – ermöglicht es einem lokalen Benutzer, seine Berechtigungen auf Root-Ebene zu erhöhen. Das Problem tritt ab Kernel-Version 5.11 auf und wird durch einen Race Condition im Implementierungsprotokoll CAN ISOTP verursacht, was die Modifikation der Binding-Parameter ermöglicht, weil in der Funktion isotp_setsockopt() bei der Verarbeitung des Flags CAN_ISOTP_SF_BROADCAST keine ordnungsgemäßen Sperren gesetzt sind.
Nach dem Schließen des ISOTP-Sockets bleibt die Bindung an den Empfängersocket bestehen, sodass dieser die an den Socket gebundenen Strukturen weiterhin nutzen kann, selbst nachdem der zugehörige Speicher freigegeben wurde (use-after-free durch den Zugriff auf die bereits freigegebene Struktur isotp_sock beim Aufruf von isotp_rcv()). Durch Datenmanipulationen kann der Funktionszeiger auf sk_error_report() überschrieben werden, was die Ausführung von eigenem Code auf Kernel-Ebene ermöglicht.
Quelle: opennet.ru
