Reverse-Engineering-Notizen und funktionierender PoC für CVE-2026-84568, eine Vertrauensgrenzenverletzung in macOS automountd, die Mounts von localhost oder dem eigenen Hostnamen des Opfers ermöglicht.

Warum dieses Writeup existiert

Apples Advisory für CVE-2026-84568 dokumentiert die Auswirkung und die Patch-Version. Sie dokumentiert nicht den technischen Mechanismus:

• Welche Funktion gepatcht wurde
• Was die Prüfung tatsächlich tut
• Warum die in der Advisory beschriebene RCE nicht über die hier getesteten Pfade erreichbar ist

Zum Zeitpunkt des Schreibens wurde kein öffentliches technisches Writeup gefunden. Dieses Repository füllt diese Lücke mit einer unabhängigen Reverse-Engineering-Analyse von automountd_26.6 und automountd_27 sowie einem funktionierenden PoC für die zugrunde liegende Trust-Boundary-Verletzung.

Dies ist kein Entdeckungsanspruch. Die CVE wurde von Mr.Gedik gemeldet und von Apple gepatcht. Der Beitrag hier ist die technische Analyse und die Reproduktion.

Zusammenfassung der Schwachstelle

automountd ruft Automount-Maps von einem konfigurierten Verzeichnisdienst (LDAP, NIS, OpenDirectory) ab. In der verwundbaren Version (26.6 und früher) validierte automountd nicht, ob die Host-Komponente eines Map-Eintrags auf die lokale Maschine auflöste.

Ein bösartiger Verzeichnisserver konnte daher einen Map-Eintrag ausliefern, dessen Mount-Quelle Folgendes war:

• der Literal-String localhost
• der eigene Hostname des Opfers (<hostname>.local)
• jede lokale IP-Adresse, einschließlich 127.0.0.1

Das Opfer würde dann von sich selbst an einem vom Angreifer kontrollierten Mount-Punkt mounten.

Die gepatchte Version (26.7 / 27) fügt eine Hostname-Prüfung in sym.func.100005bd8 hinzu, die Einträge zurückweist, die einem der oben genannten entsprechen.

Was dieses Repository enthält

Reverse Engineering

• Disassembly-Diff von sym.func.100005bd8 zwischen automountd_26.6 und automountd_27 — siehe docs/PATCH_DIFF.md
• Identifikation der gepatchten Prüfung: strncasecmp gegen "localhost", gethostname(), SCDynamicStoreCopyLocalHostName + ".local" und eine getifaddrs / getipnodebyaddr-Schleife, die alle lokalen IPs aufzählt
• Trace des fstype-Feldes durch parse_nfs → mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) — das Feld wird nicht validiert, bevor der Programmpfad konstruiert wird
• SAX-Callback-Analyse des XML-Parsers von webdavfs_agent — der characters-Callback verwendet __memcpy_chk mit expliziten Längenprüfungen; kein Overflow
• Analyse von od_process_record_attributes — der OpenDirectory-Record-Parser verwendet durchgängig CoreFoundation-APIs; keine Fixed-Size-Buffer
• Mount-Programm-Audit — mount_nfs, mount_smbfs, mount_url und alle NetFSPlugins/*-Bundles auf Shell-Ausführung geprüft; keine gefunden

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

Reproduktion

• poc.sh — ein Single-File-Setup auf Angreiferseite. Startet einen LDAP-Server mit einer bösartigen auto_master / auto_evil-Map und einen NFS-Export mit einem Proof-of-Access-Marker. Wenn automountd des Opfers die Map abruft, mountet es seinen eigenen NFS-Export am vom Angreifer kontrollierten Pfad.

Was dieser PoC demonstriert

• Einen bösartigen LDAP-Server, der eine präparierte auto_master / auto_evil-Map ausliefert
• Dass automountd des Opfers die Map über das Netzwerk abruft
• Dass das Opfer seinen eigenen NFS-Export an einem vom Angreifer kontrollierten Pfad mountet
• Dass die Mount-Quelle in der Kernel-Mount-Tabelle 127.0.0.1 ist

Was dieser PoC NICHT demonstriert

• Beliebige Codeausführung
• Privilegieneskalation
• Eine Shell auf dem Opfer

Die Auswirkung "beliebige Codeausführung mit Root-Rechten" in Apples Advisory ist nicht über die in dieser Analyse getesteten Pfade erreichbar. Siehe den Abschnitt "Paths tested and ruled out" in docs/ANALYSIS.md für die vollständige Liste.

Die demonstrierte Auswirkung ist die Trust-Boundary-Verletzung selbst: Das Opfer mountet von einer Quelle, die es hätte zurückweisen sollen.

Repository-Layout

Vier Dateien, zwei Verzeichnisse. Sonst nichts.

Anforderungen

Angreifer-Host (macOS)

• Homebrew
• OpenLDAP (brew install openldap)
• slapd.conf mit Definition: database mdb mit suffix "dc=evil,dc=local"
• NFS-Server (nfsd) — wird mit macOS ausgeliefert
• Root-Zugriff (für slapd, nfsd, /etc/exports)

Opfer-Host

• macOS 26.6 oder früher (verwundbares automountd)
• Konfiguriert, um den LDAP-Server des Angreifers nach Automount-Maps abzufragen
• +auto_master in /etc/auto_master vorhanden
• nfsd läuft auf dem Opfer und exportiert ein Verzeichnis

Das Opfer benötigt einen laufenden NFS-Server, damit der Mount erfolgreich ist. Die CVE betrifft die Akzeptanz des Local-Host-Eintrags, nicht die Bereitstellung des Exports. Wenn das Opfer kein nfsd ausführt, schlägt der Mount mit NFS server 127.0.0.1 not responding fehl — was dennoch demonstriert, dass automountd den Eintrag akzeptiert hat.

Verwendung

Angreifer

Ersetzen Sie <ATTACKER_IP> durch die IP des Angreifers, wie sie vom Opfer aus gesehen wird.

Opfer

Erwartetes Ergebnis

Die Datei proof.txt ist über den Mount lesbar. Die Mount-Quelle in der mount-Ausgabe ist 127.0.0.1:<export_dir>:

Das Vorhandensein von nodev und nosuid spiegelt die NFS-Mount-Defaults des Kernels und die eigene Optionsbehandlung von mount_nfs wider — sie stammen nicht von automountd. Siehe docs/ANALYSIS.md für die vollständige Aufschlüsselung.

Verifikation des Patches

Auf einem gepatchten System (26.7 / 27) wird derselbe Map-Eintrag vor jedem Mount-Versuch zurückgewiesen. Siehe docs/PATCH_DIFF.md für den Disassembly-Vergleich von sym.func.100005bd8.

Zur Bestätigung auf einem gepatchten Host:

Erwartet: Der Mount-Punkt wird nicht erstellt und es erscheint kein Eintrag in der mount-Ausgabe. Die Prüfung in sym.func.100005bd8 weist den Eintrag zurück, wenn der Host 127.0.0.1, localhost oder der lokale Hostname ist.

Die fstype-Injektion (separater Fund)

Während der Analyse wurde eine separate Defense-in-Depth-Schwäche gefunden: sym.func.1000086f4 (run_mount_cmd) konstruiert einen Programmpfad über asprintf("%s/mount_%s", "/sbin", fstype) ohne Validierung des fstype-Feldes aus dem Map-Eintrag.

Path-Traversal-Sequenzen in fstype erreichen den asprintf-Aufruf:

Auf einer Standard-macOS-Installation löst der resultierende Pfad nicht zu einer ausführbaren Datei auf, da /sbin/mount_.. nicht existiert. Die Injektion ist real, aber durch die Pfadauflösung blockiert. Sie würde nur dann ausnutzbar, wenn ein beschreibbarer Pfad unter /sbin existierte oder ein Verzeichnis-Symlink mount_<X> erstellt würde — beides trifft auf Standard-macOS nicht zu.

Dies ist als separate Beobachtung dokumentiert, nicht als Teil von CVE-2026-84568. Siehe docs/ANALYSIS.md für Details.

Credits

• Ursprüngliche Entdeckung: Mr.Gedik (@h4ck2s3c) von Turkish Technology, gemäß der Apple-Sicherheitsadvisory für CVE-2026-84568.
• Unabhängige Analyse und PoC: jvidhan
• Referenz: Apples Advisory und das gepatchte Binary dienten als Vergleichsbasis zur verwundbaren Version.

Haftungsausschluss

Dieses Repository wird ausschließlich für defensive Sicherheitsforschung und Bildung bereitgestellt.

• Es ist für die Verwendung gegen Systeme gedacht, die Ihnen gehören oder für die Sie eine ausdrückliche schriftliche Genehmigung zum Testen haben.
• Die Verwendung dieses Tools gegen Systeme, die Ihnen nicht gehören oder die Sie nicht kontrollieren, kann gegen lokales, nationales oder internationales Recht verstoßen.
• Der/die Autor(en) übernehmen keine Verantwortung oder Haftung für jeglichen Missbrauch oder Schaden, der durch diesen Code verursacht wird.
• Der PoC beschränkt sich auf die Demonstration einer Mount-Trust-Verletzung. Er erreicht keine Codeausführung. Jegliche Behauptungen von RCE durch diesen PoC werden durch die enthaltene Analyse nicht gestützt.
• Apple, macOS, autofs und automountd sind Marken von Apple Inc. Dieses Projekt ist nicht mit Apple verbunden oder von Apple unterstützt.

Lizenz

MIT. Siehe LICENSE.