chenaotian/cve-2023-0386Lokaler Privilege-Escalation-Exploit für CVE-2023-0386, der auf Linux-Kernel-Overlayfs abzielt. Enthält detaillierte Schwachstellenanalyse, PoC-Code und Schritt-für-Schritt-Ausnutzungsanleitung mit FUSE und User Namespaces.
gcc -Wall exp.c `pkg-config fuse --cflags --libs` -o exp
./exp /tmp
Das theoretische Wissen dieses Artikels (Namespaces, Overlay-Dateisystem, FUSE-Dateisystem usw.) stammt von ChatGPT.
Schwachstellennummer: CVE-2023-0386
Betroffenes Produkt: Linux-Kernel – Overlay-Dateisystem
Betroffene Versionen: 5.11 ~ 5.19
Ausnutzungsbedingung: unshare möglich oder Overlay-Dateisystem erstellbar
Auswirkung: Lokale Rechteausweitung
Kernel selbst kompilieren:
Bereiten Sie eine Version innerhalb des Schwachstellenbereichs vor (außer 5.15, da 5.15 anscheinend problematisch ist), aktivieren Sie die beiden Dateisysteme Overlay und FUSE:
CONFIG_SLUB_DEBUGOVERLAY_FS
CONFIG_FUSE_FS
Ubuntu 21.10 mit Kernelversion 5.13.0-16-generic wurde getestet und funktioniert:
Bevor wir die Schwachstelle analysieren, lassen wir ChatGPT einen Linux-Kernel-Experten spielen:
(ChatGPT-Frage: Im Folgenden spielst du einen Linux-Kernel-Experten und hilfst mir bei der Beantwortung einiger Fragen.)
Öffentliche Informationen über die Schwachstelle sind rar. Am direktesten ist der Patch. Der Patch-Link lautet:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a
Man sieht, dass in der Funktion ovl_copy_up_one eine zusätzliche Prüfung eingefügt wurde. Fragen wir ChatGPT, wofür diese Funktion da ist:
Diese Funktion tritt also beim Kopieren einer Datei aus der unteren in die obere Schicht des Overlay-Dateisystems auf. Dann betrachten wir die neu hinzugefügte Prüfung des Patches im Kontext:
static int ovl_copy_up_one(struct dentry *parent, struct dentry *dentry,
int flags)
{
int err;
DEFINE_DELAYED_CALL(done);
struct path parentpath;
struct ovl_copy_up_ctx ctx = {
.parent = parent,
.dentry = dentry,
.workdir = ovl_workdir(dentry),
};
if (WARN_ON(!ctx.workdir))
return -EROFS;
ovl_path_lower(dentry, &ctx.lowerpath);
err = vfs_getattr(&ctx.lowerpath, &ctx.stat,//[1] Ruft die Statistik des unteren Dateisystems ab
STATX_BASIC_STATS, AT_STATX_SYNC_AS_STAT);
if (err)
return err;
//[2] Neu hinzugefügte Prüfung: ob Benutzer-ID und Gruppen-ID der Datei im aktuellen Namespace gemappt sind
if (!kuid_has_mapping(current_user_ns(), ctx.stat.uid) ||
!kgid_has_mapping(current_user_ns(), ctx.stat.gid))
return -EOVERFLOW;
[1] Zuerst wird mit vfs_getattr die Statistik der Zieldatei im unteren Dateisystem abgerufen. vfs_getattr erhält durch Übergabe einer struct path die entsprechende struct stat-Struktur.
[1.1] ctx.lowerpath ist der Pfad einer Datei im unteren Dateisystem des Overlay-Dateisystems. Das Overlay-Dateisystem wird später beschrieben.
[1.2] Die struct stat-Struktur enthält Metadaten der Datei, einschließlich Dateieigentümer und -gruppe. Die abgerufenen Eigentümerinformationen werden in der unten neu hinzugefügten Prüfung ausgewertet.
[2] Dann wird die Funktion kuid_has_mapping aufgerufen, um die gerade abgerufenen Eigentümer- und Gruppeninformationen der Datei zu prüfen. Es wird überprüft, ob die Eigentümer- und Gruppen-ID der Zieldatei im aktuellen Benutzernamespace gemappt sind.
[2.1] kuid_has_mapping nimmt zwei Parameter entgegen: eine struct user_namespace (Benutzernamespace-Struktur) und eine struct kuid (Kernel-Benutzerstruktur). Die Funktion prüft, ob die angegebenen Benutzerinformationen im angegebenen Benutzernamespace gemappt sind. Die Mapping-Benutzer in Namespaces wird unten detailliert beschrieben.
Wir wissen also: Wenn die Operation der anfälligen Funktion (ovl_copy_up_one) ausgeführt wird und der Eigentümer oder die Gruppe der unteren Zieldatei im aktuellen Namespace nicht gemappt ist, schlägt sie fehl.
Das Prinzip des Patches ist damit klar. Dennoch müssen wir die folgenden Fragen lösen, um die Schwachstelle reproduzieren zu können:
ovl_copy_up_one ausgelöst, d. h. das Kopieren einer Datei aus der unteren in die obere Schicht des Overlay-Dateisystems?lowerpath, deren Eigentümer auf Mapping geprüft wird, in der Logikkette?Bevor wir diese beiden Fragen beantworten, müssen wir einige grundlegende Konzepte verstehen.
(ChatGPT-Frage: Bitte stelle die Namespaces im Linux-Kernel vor.)
In Linux sind Namespaces eine Kernel-Funktion zur Ressourcen-Isolation. Durch Namespaces kann eine Gruppe von Prozessen so erscheinen, als ob sie in einer unabhängigen Systemumgebung laufen, was die Sicherheit und Verwaltbarkeit des Systems verbessert. Namespaces spielen eine Schlüsselrolle in der Container-Technologie (z. B. Docker), da sie Containern ermöglichen, in isolierten Umgebungen zu laufen, ohne andere Container oder das Hostsystem zu beeinflussen.
Der Linux-Kernel unterstützt 7 Arten von Namespaces (mount, pid, net, ipc, user, time, cgroup). Jeder Namespace isoliert eine bestimmte Art von Systemressourcen. Namespaces werden durch Systemaufrufe wie clone, unshare und setns erstellt, geändert und verwaltet. Container-Runtime (z. B. Docker) und andere Virtualisierungswerkzeuge nutzen diese Namespace-Funktionen, um Containern eine unabhängige, isolierte Laufzeitumgebung zu bieten.
Die vom Patch neu hinzugefügte Prüffunktion kuid_has_mapping betrifft den Benutzernamespace (User Namespace) der oben genannten 7 Namespaces.
(ChatGPT-Frage: Bitte stelle den Benutzernamespace vor.)
Der Benutzernamespace (User Namespace) dient der Isolation von Benutzer-IDs (UIDs) und Gruppen-IDs (GIDs). Durch Benutzernamespaces können in verschiedenen Namespaces unabhängige Sätze von Benutzer- und Gruppen-IDs verwendet werden. Das bedeutet, dass ein Benutzer oder eine Gruppe in einem Namespace in einem anderen Namespace eine andere ID oder andere Rechte haben kann. Benutzernamespaces verbessern die Sicherheit und Verwaltbarkeit des Systems, insbesondere in containerisierten Umgebungen.
Eine Schlüsseleigenschaft von Benutzernamespaces ist das ID-Mapping: Benutzernamespaces erlauben es, UIDs und GIDs eines Namespace auf UIDs und GIDs eines anderen Namespace abzubilden. Das bedeutet, dass in verschiedenen Benutzernamespaces dieselbe UID/GID unterschiedliche Benutzer oder Gruppen repräsentieren kann. Beispielsweise kann der Root-Benutzer (UID 0) in einem Container im Hostsystem auf einen nicht privilegierten Benutzer gemappt sein.
Wir müssen uns nur Folgendes merken:
/proc/[pid]/uid_map; /proc/[pid]/gid_map). Diese Operation erfordert normalerweise Root-Rechte im initialen Namespace.Wenn ich z. B. als Benutzer breeze einen neuen Benutzernamespace erstelle und dann in diesem Namespace eine Datei ansehe, die Root gehört, wird der Besitzer als Nobody angezeigt: