Vor kurzem Offenlegung von Schwachstelleninformationen (CVE-2022-29582) in der Implementierung der asynchronen I/O-Schnittstelle io_uring, die seit Version 5.1 im Linux-Kernel enthalten ist und es einem nicht privilegierten Benutzer ermöglicht, root auf dem System zu werden, selbst wenn ein Container-Exploit ausgeführt wird.
Es lohnt sich das zu erwähnen besagte Schwachstelle wurde vor etwas mehr als 3 Monaten gemeldet (ungefähr Anfang Mai dieses Jahres), aber vollständige Informationen und Offenlegungen wurden erst kürzlich veröffentlicht.
In Bezug auf die Anfälligkeit wird erwähnt, dass dies tritt auf, wenn auf einen bereits freigegebenen Speicherblock zugegriffen wird, manifestiert sich in Linux-Kerneln ab dem 5.10-Zweig.
Informationen zur Sicherheitsanfälligkeit CVE-2022-29582
Diese Sicherheitslücke ermöglicht den Zugriff auf freigegebenen Speicher als Ergebnis einer Race-Condition bei der Behandlung von Zeitüberschreitungen in der Funktion io_flush_timeouts(), diee entfernt den Timeout-Eintrag aus der Liste und löscht sie, ohne die Erstellung und Löschung des Timeouts zu diesem Zeitpunkt zu überprüfen.
Eine aktualisierte allgemeine Beschreibung von io_uring wurde bereits von anderen bereitgestellt. Sie erklären es tausendmal besser als wir, also behandeln wir das Subsystem einfach ausführlicher (siehe diesen Grapl Security-Artikel und diesen Flatt Security-Artikel für eine großartige Einführung).
Was ist wichtiger, das Opcode-Feld bestimmt, welche Art von Operation auszuführen ist. Für jeden "Opcode", der dies erfordert, gibt das fd-Feld den Dateideskriptor an, an dem die angeforderte E/A auszuführen ist. Fast alle normalen E/A-Systemaufrufe (read, sendto usw.) haben einen äquivalenten asynchronen Opcode. Jedes Feld kann je nach Operation unterschiedliche Rollen einnehmen.
Einmal von der SQ abgerufen, wird eine SQE in eine interne Darstellung umgewandelt, die durch struct io_kiocb( Kernel Input/Output Call Back) beschrieben wird. Diese Objekte werden allgemein als Anforderungen bezeichnet.
struct io_kiocb wird als Äquivalent zum SQE "ready-for-launch" verwendet, auf dem es basiert, wobei jeder Dateideskriptor in struct file*s aufgelöst wird, Benutzeranmeldeinformationen angehängt werden, Personality (in denen Kerne ausgeführt werden) usw .
Nachdem die angeforderte Operation abgeschlossen ist, wird sie in die Abschlusswarteschlange geschrieben (CQ) ein Eintrag, der dem SQE entspricht. Ein solcher Eintrag wird als Completion Queue Entry (CQE) bezeichnet und enthält Felder wie einen Fehlercode und einen Ergebniswert. Die Benutzerraumanwendung kann den CQ nach neuen Einträgen abfragen, um festzustellen, ob die gesendeten SQEs die Verarbeitung beendet haben und was ihr Ergebnis war.
Es wird erwähnt, dass Es gibt einige Szenarien, in denen es einfach ist, ein Objekt zu ersetzen über den Fortschritt. Aber es gibt zwei Einschränkungen:
- LT' muss in einem Rennfenster zugewiesen und initialisiert werden. Das heißt, nachdem die LT freigegeben wurde, aber bevor ein Punkt in der LT erreicht wird, auf den nicht mehr zugegriffen wird.
- LT' kann nur ein anderes struct io_kiocb-Objekt sein. Aufgrund der Heap-Isolierung, bei der Objekte im Heap nach ihrem Typ getrennt werden, ist es zu schwierig, sie innerhalb des Rennfensters einem anderen Objekttyp zuzuweisen.
Forscher haben einen funktionalen Exploit vorbereitet die für ihren Betrieb nicht die Einbeziehung von Benutzerkennungs-Namensräumen (Benutzer-Namensräumen) erfordert und Root-Zugriff auf den Host bereitstellen kann, wenn ein nicht privilegierter Benutzer den Exploit in einem isolierten Container startet.
Unser Exploit zielt auf die Kernel-Version 5.10.90 ab, die Version, die Google zu diesem Zeitpunkt remote ausführte. Wir mussten unseren Exploit an die speziellen Spezifikationen des Servers anpassen (4 Skylake Xeon-Kerne bei 2.80 GHz, 16 GiB RAM), aber mit einigen Optimierungen sollte jeder Computer, auf dem ein anfälliger Kernel läuft, ausnutzbar sein.
Der Exploit funktioniert auch in der nsjail-Umgebung isoliert auf Google COS (Container Optimized OS)-Distribution basierend auf Chromium OS und verwendet auf Google Cloud Platform auf virtuellen Compute Engine-Maschinen. Der Exploit wurde entwickelt, um mit Kernel-Branches von 5.10 bis 5.12 zu arbeiten. Abschließend sei darauf hingewiesen das Problem wurde im April in den Updates 5.10.111, 5.15.34 und 5.17.3 behoben.
Wenn Sie mehr über die Schwachstelle erfahren möchten, können Sie schließlich die erstellte Veröffentlichung konsultieren im folgenden Link.