PinTheft: Wie eine Linux‑Kernel‑Schwachstelle Root‑Rechte ermöglicht

Wo im Linux‑Kernel der Fehler steckt

Der Bug befindet sich im RDS‑Subsystem, einem Netzwerkprotokoll des Linux‑Kernels. RDS wird vor allem in Hochleistungs‑Umgebungen eingesetzt, etwa in InfiniBand‑Clustern oder HPC‑Systemen, wo sehr schnelle Kommunikation zwischen Knoten nötig ist.

Konkret tritt der Fehler im sogenannten Zerocopy‑Send‑Pfad von RDS auf. Dieser Mechanismus erlaubt es dem Kernel, Daten direkt aus dem Userspace‑Speicher zu senden, ohne zusätzliche Kopien anzulegen. Das verbessert die Performance, macht das Speicher‑Management aber komplexer.

Die Funktion rds_message_zcopy_from_user() pinnt dabei Speicherseiten (Pages) einzeln, um sie für die Übertragung vorzubereiten. Kommt es währenddessen zu einem späteren Page Fault, versucht der Fehlerbehandlungspfad bereits gepinnte Seiten freizugeben. Unter bestimmten Bedingungen geschieht das jedoch falsch – es entsteht ein Double‑Free oder ein beschädigter Referenzzähler.

Diese Speicherinkonsistenz bildet die Grundlage für den späteren Exploit.

Wie der PinTheft‑Exploit funktioniert (vereinfacht)

Die Forscher zeigten, dass sich der RDS‑Fehler mit modernen Kernel‑Mechanismen kombinieren lässt, um aus einem Speicherbug eine zuverlässige Privileg‑Eskalation zu machen.

1. Auslösen des RDS‑Zerocopy‑Fehlers

Ein lokaler Angreifer triggert zunächst den verwundbaren Zerocopy‑Codepfad. Tritt während des Pinning‑Prozesses ein Page Fault auf, werden Seiten falsch freigegeben, obwohl sie noch referenziert werden. Das hinterlässt einen inkonsistenten Speicherzustand.

2. Wiederbelegung der freigegebenen Seiten mit io_uring

Im nächsten Schritt nutzt der Exploit io_uring Fixed Buffers. Diese Funktion ermöglicht Anwendungen, Speicherbereiche für besonders schnelle asynchrone I/O‑Operationen beim Kernel zu registrieren.

Durch gezielte Manipulation dieser Buffers kann der Angreifer die zuvor freigegebenen physikalischen Seiten kontrolliert neu belegen. Dadurch erhält er indirekten Einfluss auf den Speicherbereich, der durch den RDS‑Bug freigegeben wurde.

3. Umwandlung in einen Page‑Cache‑Overwrite

Ein entscheidender Punkt: Die betroffenen Speicherbereiche können Teil des Page‑Cache sein – also des Kernel‑Caches für Dateiinhalte.

Gelingt es dem Angreifer, diesen Speicher zu überschreiben, kann er den Inhalt manipulieren, den der Kernel ausliefert – ohne die eigentliche Datei auf der Festplatte zu verändern.

4. Manipulation eines SUID‑Root‑Programms

Im letzten Schritt zielt der Exploit auf den Page‑Cache eines SUID‑Root‑Executables. Wird dieses Programm später aus dem Cache gestartet, führt das System den manipulierten Code aus – weiterhin mit den Root‑Rechten des ursprünglichen Programms.

Das Ergebnis: Der Angreifer erhält Root‑Zugriff auf das System.

Welche Systeme besonders betroffen sind

Ob ein System tatsächlich gefährdet ist, hängt stark von seiner Kernel‑Konfiguration ab.

Arch Linux

Mehrere Sicherheitsberichte nennen Arch Linux als besonders exponiert, weil:

• ein funktionierendes Proof‑of‑Concept auf Arch demonstriert wurde
• das RDS‑Modul je nach Kernel‑Konfiguration verfügbar sein kann

Deshalb wurden Arch‑Installationen früh als Testumgebung für den Exploit verwendet.

Systeme mit aktiviertem RDS‑Modul

Prinzipiell kann jede Linux‑Distribution betroffen sein, wenn:

• ein verwundbarer Kernel läuft
• das RDS‑Kernel‑Modul geladen oder ladbar ist

Viele Enterprise‑Distributionen aktivieren dieses Modul jedoch standardmäßig nicht.

Standard‑Enterprise‑Installationen

Berichte deuten darauf hin, dass typische Installationen von Ubuntu, Debian, RHEL und AlmaLinux wahrscheinlich weniger gefährdet sind, da das RDS‑Modul dort meist nicht aktiviert ist. Administratoren sollten die konkrete Kernel‑Konfiguration jedoch überprüfen.

CloudLinux

CloudLinux gab an, den öffentlichen Exploit auf verschiedenen Plattformversionen getestet zu haben. Laut Hersteller sind diese Systeme nicht betroffen.

Voraussetzungen für eine erfolgreiche Ausnutzung

Damit der Angriff funktioniert, müssen mehrere Bedingungen erfüllt sein:

• Der Angreifer hat lokalen Codezugriff als normaler Benutzer.
• Das System verwendet einen verwundbaren Linux‑Kernel mit dem RDS‑Bug.
• Das RDS‑Kernel‑Modul ist verfügbar oder kann geladen werden.
• io_uring ist für unprivilegierte Nutzer nutzbar.
• Ein SUID‑Root‑Binary oder ein anderes privilegiertes Programm ist vorhanden.

Fehlt eine dieser Voraussetzungen, wird der Exploit deutlich schwieriger oder unmöglich.

Schutzmaßnahmen und Empfehlungen

Administratoren können das Risiko deutlich reduzieren.

Kernel‑Updates installieren

Kernel‑Maintainer haben bereits einen Fix für den betroffenen RDS‑Code veröffentlicht. Das wichtigste Gegenmittel ist daher ein Update auf die aktuelle Kernel‑Version der Distribution.

Nach einem Kernel‑Update ist ein Neustart des Systems erforderlich, damit der Patch wirksam wird.

RDS‑Modul deaktivieren

Wenn RDS in der eigenen Infrastruktur nicht benötigt wird, sollte das Modul nicht geladen werden.

Typische Maßnahmen sind:

• Blacklisting des rds‑Moduls
• Entfernen aus Autoload‑Konfigurationen

io_uring für unprivilegierte Nutzer einschränken

Da der Exploit auf io_uring Fixed Buffers basiert, kann eine Einschränkung oder Deaktivierung für normale Benutzer die Angriffsfläche reduzieren.

SUID‑Programme überprüfen

Der Angriff nutzt letztlich ein SUID‑Root‑Binary. Administratoren sollten daher prüfen:

• welche Programme wirklich SUID benötigen
• ob unnötige SUID‑Bits entfernt werden können

Lokalen Zugriff begrenzen

Da PinTheft lokalen Codezugriff voraussetzt, sollten besonders Multi‑User‑Systeme priorisiert gepatcht werden, etwa:

• CI‑Runner
• Shared‑Hosting‑Server
• Entwickler‑ oder Laborumgebungen

Was der Fall PinTheft zeigt

PinTheft ist ein gutes Beispiel dafür, wie moderne Kernel‑Exploits funktionieren: Sie kombinieren mehrere komplexe Subsysteme – hier RDS‑Netzwerkcode und das io_uring‑I/O‑Framework – um aus einem scheinbar kleinen Speicherfehler eine vollständige Privileg‑Eskalation zu machen.

Die wichtigste Lehre bleibt deshalb unverändert: Kernel regelmäßig aktualisieren und unnötige Module deaktivieren. Selbst selten genutzte Komponenten können sonst zu einem kritischen Angriffspunkt werden.