CVE-2026-28912 — Reverse-Engineering-Notizen und Reproduktion

Unabhängiges Reverse Engineering des macOS-PackageKit-Symlink-Following-Bugs (CVE-2026-28912) sowie ein funktionierender PoC, der demonstriert, wie der Installer eine vom Angreifer kontrollierte Datei als root über einen Verzeichnis-Symlink im Installationszielpfad schreibt.

Der Bug ist ein unsynchronisierter Pfad-Durchlauf in der Datei-Relink-Logik von PKCoreShove. Ein bösartiges .pkg kann einen Zielpfad in einem unprivilegierten Verzeichnis deklarieren, an einer der Pfadkomponenten einen Verzeichnis-Symlink platzieren, der auf einen privilegierten Ort zeigt, und den Installer — der als root läuft — dazu bringen, in das Symlink-Ziel zu schreiben. Apples 26.6-Fix fügt _PKSIPOpenPathSafely hinzu, das jede Pfadkomponente mit O_NOFOLLOW durchläuft und jeden Symlink ablehnt.

CVE auf einen Blick

Feld	Wert
CVE	CVE-2026-28912
Komponente	PackageKit (PKCoreShove, PKBundleComponent)
Betroffen	macOS Tahoe 26.5 und früher
Gepatcht in	macOS Tahoe 26.6
Auswirkung laut Advisory	"Eine App kann möglicherweise Root-Rechte erlangen."
CVSS v3.1	7.8 (Hoch)
Gemeldet von	Ursprüngliche Finder gemäß Apples Advisory

Warum dieses Writeup existiert

Apples Advisory für CVE-2026-28912 dokumentiert die Auswirkung und die gepatchte Version. Es dokumentiert nicht den technischen Mechanismus:

Welche Funktion in PackageKit dem Symlink folgt
Warum der Installer den Zielpfad durchläuft, ohne jede Komponente zu prüfen
Welche Funktion in 26.6 hinzugefügt wurde, um den Bug zu schließen
Warum der Fix genau an dieser Stelle einen O_NOFOLLOW-Durchlauf einfügt
Warum der PoC einen Verzeichnis-Symlink statt eines Datei-Symlinks verwenden muss
Warum ein Datei-Symlink am Ziel ersetzt statt befolgt wird

Zum Zeitpunkt des Verfassens wurde kein öffentliches technisches Writeup gefunden. Dieses Repository füllt diese Lücke mit einer unabhängigen Reverse-Engineering-Analyse von PackageKit zwischen 26.4 und 26.6 sowie einem funktionierenden PoC, der das Primitiv live demonstriert.

Dies ist kein Entdeckungsanspruch. Die CVE wurde von den ursprünglichen Findern gemeldet und von Apple gepatcht. Der Beitrag hier ist die technische Analyse und die Reproduktion.

Zusammenfassung der Schwachstelle

PKCoreShove _relinkFile:dest: in macOS 26.4 durchläuft den Zielpfad Komponente für Komponente beim Erstellen einer Datei:

; macOS 26.4, PackageKit
1a9fb14f8   _relinkFile:dest:
    ...
    bl   _linkResolutionProhibitted     ; returns 0 in the normal case
    mov  w8, 0x10                       ; RENAME_NOFOLLOW_ANY
    cmp  w0, 0
    csel w22, w8, wzr, ne               ; w22 = 0x10 if prohibited, else 0
    ...
    mov  x2, x22
    bl   _renamex_np                    ; uses w22 as flags

_linkResolutionProhibitted gibt 0 (false) zurück, wenn der aufrufende Prozess keine SIP-Dateien ändern kann — der Normalfall bei einer benutzerinitiierten Installation. Dadurch wird RENAME_NOFOLLOW_ANY deaktiviert, sodass das Rename jedem Symlink im Zielpfad folgt.

Der 26.6-Fix fügt _PKSIPOpenPathSafely hinzu, aufgerufen aus PKBundleComponent initWithBundleAtPath:relativeToDestination::

; macOS 26.6, PackageKit
1aa6dfe18   bl   _PKSIPOpenPathSafely    ; walks each component with O_NOFOLLOW

_PKSIPOpenPathSafely:

Öffnet jede Pfadkomponente mit O_NOFOLLOW (0x4)
Erkennt Symlinks über S_IFLNK (0xa000 in st_mode)
Prüft SIP-Schutz über _PKSIPFullyProtected
Liest SF_RESTRICTED über fgetattrlist
Verwendet close_drop_np, um die Sandbox-Erweiterung beim Aufräumen zu entfernen

Jede Komponente, die ein Symlink ist und außerhalb des beabsichtigten Pfads zeigt, wird mit EPERM oder ELOOP abgelehnt, und die Installation schlägt fehl.

Was dieses Repository enthält

Reverse Engineering

Disassembly-Diff von PKCoreShove _relinkFile:dest: und _linkResolutionProhibitted zwischen 26.4 und 26.6
Identifikation des verwundbaren Feldes: _linkResolutionProhibitted gibt 0 für Nicht-SIP-ändernde Prozesse zurück
Identifikation des Fixes: _PKSIPOpenPathSafely zu PKBundleComponent hinzugefügt, O_NOFOLLOW-Durchlauf pro Komponente
Syscall-Analyse: Installer verwendet renamex_np mit RENAME_NOFOLLOW_ANY = 0x10 nur, wenn der Aufrufer SIP-Dateien ändern kann
Laufzeitbestätigung: fs_usage zeigt, wie der Installer stat/listxattr auf dem Symlink-Ziel ausführt und durch den Verzeichnis-Symlink schreibt

Siehe docs/ANALYSIS.md für das vollständige Writeup und docs/ARTIFACTS.md für Adressen und Log-Beispiele.

Reproduktion

link.sh — ein einzelfile, eigenständiger PoC:
1. Erstellt einen Verzeichnis-Symlink bei $HOME/cve-poc/target → $HOME/cve-poc/real
2. Baut ein .pkg, dessen Payload eine Datei bei $HOME/cve-poc/target/poc.txt deklariert
3. Installiert es mit sudo installer
4. Verifiziert, dass die Datei in $HOME/cve-poc/real/poc.txt gelandet ist — mit root:wheel-Eigentümerschaft

Was dieser PoC demonstriert

Ein .pkg-Payload, das eine Datei unter einem unprivilegierten Verzeichnis deklariert
Der Installer folgt einem Verzeichnis-Symlink an diesem Pfad
Eine root-eigene Datei wird außerhalb des deklarierten Ziels erstellt
Live-Erfassung des Schreibvorgangs über fs_usage

Was dieser PoC NICHT demonstriert

Einen Datei-Symlink am Ziel. Datei-Symlinks werden durch renamex_np ersetzt, nicht befolgt — der Schreibvorgang muss über einen Verzeichnis-Symlink im Pfad erfolgen.
Codeausführung, Privilegieneskalation oder eine Shell auf dem Opfer
Waffenfähigkeit: Der PoC verwendet standardmäßig $HOME/cve-poc/real/, nicht /etc/sudoers.d/ oder /Library/LaunchDaemons/

Die demonstrierte Auswirkung ist das Symlink-Following-Primitiv — genau das Verhalten, das der 26.6-Fix schließt.

Anforderungen

Ziel-(Opfer-)Host

macOS Tahoe 26.5 oder früher (verwundbares PackageKit)
pkgbuild, installer, fs_usage
Root (für den Installer)

Kein separater Angreifer-Host erforderlich

Der PoC läuft vollständig auf dem Ziel. Der Symlink und das Payload werden beide lokal erstellt. Dadurch bleibt der PoC eigenständig und reproduzierbar ohne Netzwerkkonfiguration.

Verwendung

chmod +x link.sh
./link.sh

Optionale Anpassung über Umgebungsvariablen:

sudo CONTENT="test content" ./link.sh

CONTENT legt den Inhalt fest, der durch den Symlink geschrieben wird. Standardmäßig ist es hello.

Erwartete Ausgabe

[*] System information:
ProductName:        macOS
ProductVersion:     26.4
BuildVersion:       25E246

[*] Setup...
    Symlink:  /Users/nerd/cve-poc/target → /Users/nerd/cve-poc/real

[*] Build .pkg...
    Payload:  /Users/nerd/cve-poc/payload/Users/nerd/cve-poc/target/poc.txt
    Package:  /Users/nerd/cve-poc/poc.pkg

[*] Install (password prompt expected)...
installer: Package name is poc
installer: Installing at base path /
installer: The install was successful.

[✓] VULNERABILITY CONFIRMED
    Landed at /Users/nerd/cve-poc/real/poc.txt
    Owner:   root:wheel
    Content: hello

CVE-2026-28912 trigger SUCCESSFUL

Verifikation des Patches

Auf einem gepatchten System (26.6) schlägt derselbe PoC fehl:

[✗] Not triggered
No file was created in /Users/nerd/cve-poc/real/

Siehe docs/PATCH_DIFF.md für den Disassembly-Vergleich.

.pkg-Stolperfallen (für Reproduzierbarkeit)

Zwei Details im PoC wurden während der Entwicklung entdeckt und sind hier dokumentiert, damit andere, die ähnliche Tooling bauen, nicht darüber stolpern:

Der Symlink muss sich an einer Pfadkomponente befinden, die der Installer durchläuft. Ein Datei-Symlink am Ziel-Blatt wird durch renamex_np ersetzt; nur ein Verzeichnis-Symlink in der Mitte des Pfads wird befolgt.

cve-2026-28912

Beliebteste