CVE-2026-7867-disk2root

Filesystem.Mount → as-user Spoofing → Authorization Bypass → Root-context Mount → LPE

Übersicht

CVE-2026-7867 ist eine lokale Privilegienausweitungsschwachstelle in udisks2, die die D-Bus-Methode Filesystem.Mount, die Option as-user, fstab-gesteuerte Mount-Abläufe und eine fehlerhafte Autorisierungsbehandlung betrifft.

Dieses private Repository enthält die technischen Forschungsnotizen und Proof-of-Concept-Skripte, die zur Validierung des Problems in einer kontrollierten Laborumgebung verwendet wurden.

Die Schwachstelle wurde entdeckt und gemeldet von:

Das Problem wurde zugewiesen:

CVE-2026-7867

Zusammenfassung

Die Schwachstelle wird durch eine fehlerhafte Vertrauensbeziehung zwischen der tatsächlichen D-Bus-Aufrufer-UID und der berechneten/effektiven UID, die durch die Mount-Option as-user erzeugt wird, verursacht.

In anfälligen Abläufen kann ein unprivilegierter lokaler Benutzer den Mount-Ausführungspfad so beeinflussen, dass ein Dateisystem-Mount in einem privilegierten/Root-Kontext ohne das erwartete PolicyKit-Autorisierungsverhalten durchgeführt wird.

Der Kernfehler ist nicht einfach "benutzergesteuerte Mount-Optionen".

Das eigentliche Problem ist:

udisks2 versäumt es, die ursprüngliche Aufruferidentität während der fstab-Mount-Autorisierung und -Ausführung konsistent von der berechneten as-user-Identität zu unterscheiden.

Schwachstelle auf einen Blick

Betroffener Bereich

Die anfällige Logik ist mit dem fstab-Mount-Abwicklungspfad innerhalb von udisks2 verbunden, insbesondere wenn die Mount-Anfrage beinhaltet:

Filesystem.Mount
as-user
x-udisks-auth
user
users

Die relevanten sicherheitssensitiven Bereiche sind:

D-Bus-Aufruferidentität
        ↓
as-user-Optionsbehandlung
        ↓
fstab-Autorisierungslogik
        ↓
PolicyKit-Entscheidungsablauf
        ↓
Root-Kontext-Mount-Ausführung

Angriffsablauf

┌─────────────────────────────┐
│ Unprivilegierter lokaler    │
│ Benutzer                    │
└──────────────┬──────────────┘
               │
               │ Filesystem.Mount
               │ mit as-user-Einfluss
               ▼
┌─────────────────────────────┐
│ udisks2 / udisksd           │
│ privilegierter Systemdienst │
└──────────────┬──────────────┘
               │
               │ fstab-Logik wertet
               │ Benutzer-/Auth-Optionen aus
               ▼
┌─────────────────────────────┐
│ Autorisierungslücke         │
│ mount_other_user wird       │
│ im übersprungenen Pfad      │
│ nicht erzwungen             │
└──────────────┬──────────────┘
               │
               │ Root-Kontext-Zweig erreicht
               ▼
┌─────────────────────────────┐
│ Dateisystem gemountet       │
│ ohne erwarteten Auth-Ablauf │
└──────────────┬──────────────┘
               │
               │ Auswirkung hängt von Mount-Flags ab
               ▼
┌─────────────────────────────┐
│ Lokale Privilegienausweitung│
│ kontrollierte Laborvalidierung│
└─────────────────────────────┘

Ursache

Das anfällige Verhalten wird durch einen Identitätsverwirrungsfehler verursacht.

Das System hat mehrere Identitätskonzepte:

tatsächliche D-Bus-Aufrufer-UID
berechnete as-user-UID
effektive Mount-UID
udisksd-Daemon-Privilegienkontext

Der anfällige Ablauf setzt diese Identitäten nicht konsistent durch.

Insbesondere:

• mount_other_user kann wahr werden, weil as-user verwendet wird
• fstab-Optionen wie x-udisks-auth, user oder users können den Autorisierungspfad beeinflussen
• der Autorisierungsblock kann übersprungen werden
• die mount_other_user-Prüfung wird außerhalb dieses Blocks nicht zuverlässig erzwungen
• der Mount-Pfad kann einen Zweig erreichen, der für echte Root-/Admin-Ausführung vorgesehen ist
• der Mount wird vom privilegierten Daemon-Kontext durchgeführt

Das Ergebnis ist eine Umgehung der lokalen Privilegiengrenze.

Das x-udisks-auth-Problem

Die Option x-udisks-auth soll einen administrativen PolicyKit-Autorisierungsablauf erzwingen.

Erwartetes Verhalten:

Mount-Anfrage
    ↓
Versuch, Mount als Aufrufer durchzuführen
    ↓
Berechtigungs-/Auth-Fehler
    ↓
PolicyKit-Prüfung filesystem-fstab
    ↓
Admin-Genehmigung
    ↓
Mount als autorisierte privilegierte Aktion

Anfälliges Verhalten:

Mount-Anfrage mit as-user-Einfluss
    ↓
berechnete Identität beeinflusst Ausführung
    ↓
Mount gelingt zu früh
    ↓
PolicyKit-Auth-Pfad wird wie erwartet nicht erreicht
    ↓
privilegierter Mount-Zustand wird erreicht

Dies macht das Sicherheitsmodell um x-udisks-auth im anfälligen Pfad unzuverlässig.

Verletzung des Sicherheitsmodells

Erwartetes Modell:

Unprivilegierter Benutzer
    ↓
D-Bus-Mount-Anfrage
    ↓
PolicyKit / fstab-Autorisierung
    ↓
eingeschränktes Mount-Verhalten

Gebrochenes Modell:

Unprivilegierter Benutzer
    ↓
D-Bus-Mount-Anfrage mit as-user-Spoofing
    ↓
Autorisierungslogik-Mismatch
    ↓
Root-Kontext-Mount-Ausführung

Der Fehler ist besonders schwerwiegend, weil der betroffene Dienst mit erhöhten Privilegien läuft.

Auswirkungen

Eine erfolgreiche Ausnutzung kann es einem lokalen unprivilegierten Benutzer ermöglichen, ein Dateisystem über udisks2 in einem Root-Kontext-Ausführungspfad zu mounten, ohne die erwartete Autorisierungsabfrage.

Je nach Dateisystem und Mount-Flags können die Auswirkungen umfassen:

• lokale Privilegienausweitung
• unbefugtes Mounten von Dateisystemen im Root-Kontext
• Umgehung der erwarteten PolicyKit-Autorisierung
• unsicheres fstab-verwaltetes Gerätemounting
• setuid-basierte Eskalation in betroffenen Laborkonfigurationen
• unerwartete Ausführung von Dateien aus angreifergesteuerten oder vorbereiteten Dateisystemen

Ausnutzungsbedingungen

Dies ist eine lokale Schwachstelle.

Relevante Bedingungen sind:

Repository-Struktur

.
├── README.md
├── disk2root.sh              ← Hauptexploit (eigenständiges LPE)
└── poc/
    ├── setup_lpe_env.sh       ← Laboreinrichtung
    ├── f2_mount_as_user_bypass.sh
    ├── f2_check_nosuid.sh
    ├── f2_suid_test.sh
    ├── f2_final.sh
    └── cleanup_lpe_env.sh

Exploit — disk2root.sh

Eigenständiger, nutzbarer Exploit. Erstellt sein eigenes SUID-Root-Payload, erstellt ein vorbereitetes Festplattenimage, mountet es über den as-user=root-Polkit-Bypass und öffnet eine Root-Shell.

Schnellstart

Option 1 — Als Root ausführen (funktioniert überall, einschließlich SSH):

./disk2root.sh

Das Skript erledigt automatisch:

1. Kompiliert ein statisches SUID-Root-Shell-Binary
2. Erstellt ein 32MB-ext4-Image auf einem Loop-Gerät
3. Injiziert das Binary mit uid=0 mode=4755 via debugfs
4. Fügt einen fstab-Eintrag mit x-udisks-auth hinzu
5. Wechselt zu einem unprivilegierten Benutzer via su
6. Ruft Filesystem.Mount mit as-user=root auf (Polkit-Bypass)
7. Führt das SUID-Binary aus → Root-Shell
8. Räumt alles beim Beenden auf

Um anzugeben, von welchem Benutzer aus eskaliert werden soll:

./disk2root.sh testuser

Wenn kein Benutzer angegeben wird, wählt das Skript den ersten regulären Benutzer im System oder erstellt einen temporären.

Option 2 — Als unprivilegierter Benutzer ausführen (Desktop / aktive Sitzung):

./disk2root.sh

Auf Systemen mit einer aktiven Polkit-Sitzung (Desktop-Login, GNOME/KDE) ist das Skript vollständig eigenständig – es erstellt sein eigenes Loop-Gerät via udisksctl oder D-Bus LoopSetup, mountet via as-user=root und eskaliert ohne vorherige Einrichtung.

Option 3 — Als unprivilegierter Benutzer ausführen (SSH, nach Einrichtung):

Wenn die Umgebung bereits vorbereitet wurde (z. B. durch Ausführen von poc/setup_lpe_env.sh als Root oder durch einen vorherigen ./disk2root.sh-Lauf als Root), kann jeder unprivilegierte Benutzer erneut ausnutzen:

./disk2root.sh

Das Skript erkennt automatisch anfällige fstab-Einträge und verwendet sie.

Bereinigung

./disk2root.sh --cleanup

Entfernt alle Artefakte: fstab-Eintrag, Loop-Gerät, Mount-Punkt, temporären Benutzer.

Strategiekaskade

Wenn als unprivilegiert ausgeführt, probiert das Skript mehrere Pfade in Reihenfolge:

[A] Eigenständig
    Payload erstellen → ext4-Image erstellen → debugfs SUID-Binary injizieren
    → Loop-Setup (python3 GIO / udisksctl) → Mount as-user=root
    ✓ funktioniert auf Desktop-Sitzungen

[B] Fstab-Fallback
    /etc/fstab auf x-udisks-auth / user / users-Einträge durchsuchen
    → Mount as-user=root → SUID-Binary auf gemountetem FS finden
    ✓ funktioniert auf SSH, wenn Umgebung vorbereitet ist

Beispielausgabe

╔═════════════════════════════════════════════════════╗
║  CVE-2026-7867 — disk2root                          ║
║  udisks2 as-user polkit bypass → LPE root shell     ║
╚═════════════════════════════════════════════════════════╝

[*] uid=1002 (testuser) — exploite...
    fstab: /dev/loop5 → /mnt/disk2root (x-udisks-auth)
    gemountet: /mnt/disk2root
    nosuid: nicht gesetzt
    suid: pwn (4755 root:root)

╔═════════════════════════════════════════════════════╗
║  Wechsel zu Root-Shell — 'exit' eingeben, um        ║
║  zurückzukehren                                     ║
╚═════════════════════════════════════════════════════════╝

[+] Root-Shell — uid=0 euid=0
root@target:/tmp#

Anforderungen

PoC-Skripte (poc/)

Einzelne Validierungsskripte, die während der Forschung verwendet wurden. Dies sind die Bausteine, die zu disk2root.sh führten.

Laborablauf (mit einzelnen PoC-Skripten)

1. poc/setup_lpe_env.sh als Root ausführen
2. su - testuser
3. poc/f2_mount_as_user_bypass.sh ausführen
4. poc/f2_final.sh zur vollständigen Validierung ausführen
5. poc/cleanup_lpe_env.sh als Root ausführen

Oder einfach disk2root.sh verwenden, das alle oben genannten Schritte kombiniert.

Technische Primitive

Die durch diese Forschung demonstrierte Primitive ist:

as-user-Options-Spoofing innerhalb privilegierter Mount-Orchestrierung

Der kritische Übergang ist:

unprivilegierter D-Bus-Aufrufer
        ↓
gespoofte/berechnete Mount-Identität
        ↓
Autorisierungspfad-Verwirrung
        ↓
Root-Kontext-Mount-Ausführung

Deshalb qualifiziert sich das Problem als lokale Privilegienausweitungsschwachstelle.

Warum dieser Fehler wichtig ist

udisks2 wird allgemein als privilegierter Speicherverwaltungsdienst vertraut.

Ein Fehler in dieser Ebene hat hohe Auswirkungen, da er zwischen folgendem sitzt:

Desktop-/Sitzungsbenutzern
D-Bus-Methodenaufrufen
PolicyKit-Autorisierung
Dateisystem-Mount-Operationen
Root-Daemon-Privilegien

Ein Fehler in der Identitätsbehandlung hier kann sich direkt auf lokale Privilegiengrenzen auswirken.

Erkennungsideen

Verteidiger können verdächtige udisks2-Mount-Aktivitäten überwachen, die as-user betreffen.

Nützliche Telemetriequellen:

udisksd-Protokolle
D-Bus-Methodenaufrufe
PolicyKit-Protokolle
Mount-Tabellenänderungen
/proc/mounts
/etc/fstab
journalctl

Nützliche Befehle:

findmnt
mount
cat /proc/mounts
journalctl -u udisks2
journalctl | grep -i udisks
journalctl | grep -i polkit

Verdächtige Muster:

Nicht-Root-Benutzer löst Filesystem.Mount aus
as-user=root Verwendung
Unerwarteter Mount ohne PolicyKit-Abfrage
Mounts ohne nosuid/noexec/nodev
setuid-Ausführung von kürzlich gemounteten Dateisystemen
Unerwartete Loop-Gerät-Mounts

Abhilfe

udisks2 aktualisieren

Wenden Sie den vom Anbieter bereitgestellten Fix an, sobald verfügbar.

Geplante Fix-Veröffentlichung:

udisks 2.11.2

fstab-Einträge überprüfen

Prüfen Sie Einträge mit:

x-udisks-auth
user
users

Überprüfen Sie insbesondere Dateisysteme, die ausführbare oder setuid-Inhalte enthalten können.

Lokalen Shell-Zugriff einschränken

Da es sich um eine lokale Schwachstelle handelt, reduziert die Einschränkung des nicht vertrauenswürdigen lokalen Zugriffs die Gefährdung.

Mount-Aktivität überwachen

Überwachen Sie unerwartete Mount-Operationen durch:

udisksd

insbesondere, wenn sie von Nicht-Root-Benutzern ausgelöst werden.

Sicherere Mount-Flags erzwingen

Wo anwendbar, verwenden Sie:

nosuid
noexec
nodev

Diese Flags können die Auswirkungen nach dem Mount verringern.

PolicyKit-Regeln härten

Überprüfen Sie PolicyKit-Regeln im Zusammenhang mit udisks-Mount-Aktionen.

Stellen Sie sicher, dass unprivilegierte Benutzer ohne explizite Autorisierung keine sensiblen Mount-Pfade auslösen können.

Fix-Richtung

Ein robuster Fix sollte sicherstellen, dass:

• die ursprüngliche D-Bus-Aufrufer-UID beibehalten wird
• die berechnete as-user-UID nicht die Aufruferidentität für die Autorisierung ersetzt
• mount_other_user immer ordnungsgemäße PolicyKit-Prüfungen auslöst
• die Root-Kontext-Mount-Ausführung auf echte autorisierte Root-/Admin-Abläufe beschränkt ist
• x-udisks-auth konsistent die Authentifizierung erzwingt
• verwandte Codepfade wie die Handhabung verschlüsselter Dateisysteme geprüft werden

Offenlegungszeitplan

Credits

Plan zur öffentlichen Veröffentlichung

Nach Aufhebung der Embargofrist kann dieses Repository in ein öffentliches Forschungs-Repo umgewandelt werden mit:

docs/
├── technical-analysis.md
├── root-cause.md
├── lab-setup.md
├── exploit-flow.md
├── detection.md
└── mitigation.md

Empfohlene öffentliche Ergänzungen:

• offizieller CVE-Link
• Red-Hat-Bulletin-Link
• Upstream-Patch-Link
• Matrix der betroffenen/behobenen Versionen
• sichere Reproduktionsanleitung
• Hinweise zur kontrollierten PoC-Nutzung
• Leitfaden zur Erkennung und Härtung

Haftungsausschluss

Dieses Repository ist nur für autorisierte Sicherheitsforschung, Anbieterkoordination und defensive Validierung bestimmt.

Die PoC-Skripte sind für isolierte Testumgebungen gedacht.

Führen Sie diese Skripte nicht auf Systemen aus, die Ihnen nicht gehören oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben.

Die Autoren sind nicht verantwortlich für Missbrauch dieser Forschung.

CVE-2026-7867
udisks2 Lokale Privilegienausweitung – Forschung