10
Vor ein paar Tagen wurde die Nachricht veröffentlicht, dass Im Linux-Kernel wurden zwei Sicherheitslücken identifiziert Der erste von ihnen wurde bereits als CVE-2022-0435 katalogisiert und wurde im Linux-Kernel-Modul gefunden, das den Betrieb des TIPC-Netzwerkprotokolls (Transparent Inter-Process Communication) bereitstellt.
Diese Sicherheitslücke könnte zulassen, dass Code auf Kernel-Ebene ausgeführt wird durch Senden eines Pakets an ein speziell entwickeltes Netzwerk.
Das Problem betrifft nur Systeme mit geladenem Kernelmodul tipc.ko und mit dem TIPC-Stack konfiguriert, der normalerweise in Clustern verwendet wird und auf nicht spezialisierten Linux-Distributionen standardmäßig nicht aktiviert ist.
Verletzlichkeit Es wird durch einen Stapelüberlauf verursacht, der bei der Verarbeitung von Paketen auftritt, der Wert des Felds mit der Anzahl der Mitgliedsknoten der Domäne, in der er 64 überschreitet.
Um die Parameter der Knoten im tipc.ko-Modul zu speichern, setzt ein Array "u32-Mitglieder[64]", aber im Prozess der Verarbeitung dessen, was im Paket angegeben ist. Die Knotennummer überprüft nicht den Wert „member_cnt“, wodurch Werte größer als 64 zum kontrollierten Überschreiben von Daten im Speicherbereich darunter verwendet werden können. den Stack nach der "dom_bef"-Struktur.
Das TIPC-Protokoll wurde ursprünglich von Ericsson entwickelt, es soll die Kommunikation zwischen Prozessen in einem Cluster organisieren und wird hauptsächlich auf den Knoten des Clusters aktiviert. TIPC kann sowohl über Ethernet als auch über UDP (Netzwerkport 6118) arbeiten.
Bei der Arbeit über Ethernet kann ein Angriff aus dem lokalen Netzwerk und bei UDP aus dem globalen Netzwerk erfolgen, wenn der Port nicht durch eine Firewall abgedeckt ist. Der Angriff kann auch von einem lokalen Benutzer ohne Privilegien auf dem Host durchgeführt werden. Um TIPC zu aktivieren, müssen Sie das Kernelmodul tipc.ko laden und die Bindung an eine Netzwerkschnittstelle mit netlink oder dem Dienstprogramm tipc konfigurieren.
Es wird das erwähnt beim Erstellen des Kernels im "CONFIG_FORTIFY_SRC=y"-Modus (wird in RHEL verwendet), das der Funktion memcpy() zusätzliche Begrenzungsprüfungen hinzufügt, Der Betrieb ist auf einen Notstopp beschränkt (Kernel wechselt in den Zustand „Kernel Panic“).
Wenn es ohne zusätzliche Überprüfungen ausgeführt wird und Informationen über die zum Schutz des Stacks verwendeten Canary-Flags durchgesickert sind, kann das Problem verwendet werden, um Code mit Kernel-Rechten aus der Ferne auszuführen. Die Forscher, die das Problem identifiziert haben, sagen, dass die Exploit-Technik trivial ist und nach der weit verbreiteten Beseitigung der Schwachstelle in Distributionen aufgedeckt wird.
Der Fehler, der die Schwachstelle generiert hat, wurde am 15. Juni 2016 eingeführt und wurde Teil des Linux 4.8-Kernels. Verletzlichkeit in Kernel-Versionen behoben Linux 5.16.9, 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266 und 4.9.301.
Eine weitere Sicherheitslücke die im Linux-Kernel gefunden wurde ist CVE-2022-24122 im Code, um rlimit-Einschränkungen zu behandeln in verschiedenen Benutzernamensräumen.
Der Fehler wurde in einer im Sommer 2021 hinzugefügten Änderung eingeführt, Verschieben der Implementierung einiger RLIMIT-Zähler zur Verwendung der "ucounts"-Struktur. Die für RLIMIT erstellten "ucounts"-Objekte wurden weiterhin verwendet, nachdem der ihnen zugewiesene Speicher (use-after-free) freigegeben wurde, indem der ihnen zugeordnete Namespace entfernt wurde, wodurch die Ausführung ihres Codes auf Kernel-Ebene ermöglicht wurde.
Die Ausnutzung der Schwachstelle durch einen nicht privilegierten Benutzer ist nur möglich, wenn das System einen nicht privilegierten Zugriff auf den Benutzerkennungs-Namespace (unprivilegierter Benutzer-Namespace) hat, der standardmäßig in Ubuntu und Fedora aktiviert ist, aber nicht in Debian und RHEL.
Als Problemumgehung zum Blockieren der Schwachstelle können Sie den nicht privilegierten Zugriff auf den Namespace des Benutzers deaktivieren:
sysctl -w kernel.unprivileged_userns_clone=0
Das Problem gibt es seit dem Linux-Kernel 5.14 und wird in den Updates 5.16.5 und 5.15.19 behoben. Die Stable-Zweige von Debian, Ubuntu, SUSE/openSUSE und RHEL sind von dem Problem nicht betroffen, tauchen aber in neuen Fedora- und Arch-Linux-Kerneln auf.