jvidhan/autofs-cve-2026-84568Reverse-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.
Unabhängiges Reverse Engineering des macOS-autofs-Patches für CVE-2026-84568, plus ein funktionierender PoC für die Trust-Boundary-Verletzung.
Apple hat die Advisory veröffentlicht. Mr.Gedik (@h4ck2s3c) hat den Bug gemeldet. Dieses Repository dokumentiert den technischen Mechanismus — die gepatchte Funktion, was die Prüfung tut und welche Mount-Pfade der Patch blockiert — und enthält einen funktionierenden PoC, der die Trust-Verletzung auf einem verwundbaren System reproduziert.
| Feld | Wert |
|---|---|
| CVE | CVE-2026-84568 |
| Komponente | autofs / automountd |
| Betroffen | macOS Tahoe 26.6 und früher |
| Gepatcht in | macOS Tahoe 26.7, macOS Golden Gate 27, macOS Sequoia 15.8 |
| Advisory-Auswirkung | "Ein Angreifer mit Kontrolle über einen Netzwerk-Verzeichnisserver kann möglicherweise beliebigen Code mit Root-Rechten ausführen." |
| Gemeldet von | Mr.Gedik (@h4ck2s3c) von Turkish Technology |
Apples Advisory für CVE-2026-84568 dokumentiert die Auswirkung und die Patch-Version. Sie dokumentiert nicht den technischen Mechanismus:
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.
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:
localhost<hostname>.local)127.0.0.1Das 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.
sym.func.100005bd8 zwischen automountd_26.6
und automountd_27 — siehe docs/PATCH_DIFF.mdstrncasecmp gegen
"localhost", gethostname(), SCDynamicStoreCopyLocalHostName +
".local" und eine getifaddrs / getipnodebyaddr-Schleife, die
alle lokalen IPs aufzähltfstype-Feldes durch parse_nfs →
mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) —
das Feld wird nicht validiert, bevor der Programmpfad konstruiert wirdwebdavfs_agent — der
characters-Callback verwendet __memcpy_chk mit expliziten
Längenprüfungen; kein Overflowod_process_record_attributes — der
OpenDirectory-Record-Parser verwendet durchgängig CoreFoundation-APIs;
keine Fixed-Size-Buffermount_nfs, mount_smbfs, mount_url
und alle NetFSPlugins/*-Bundles auf Shell-Ausführung geprüft; keine
gefundenSiehe docs/ANALYSIS.md für das vollständige
Writeup und docs/ARTIFACTS.md für Adressen und
Log-Beispiele.
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.auto_master / auto_evil-Map ausliefertautomountd des Opfers die Map über das Netzwerk abruft127.0.0.1 istDie 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.
poc.sh Setup auf Angreiferseite (einzelne Datei)
docs/
ANALYSIS.md vollständiges Reverse-Engineering-Writeup
PATCH_DIFF.md sym.func.100005bd8 Diff zwischen 26.6 und 27
ARTIFACTS.md Adressen und Log-Beispiele
README.md diese Datei
LICENSE
Vier Dateien, zwei Verzeichnisse. Sonst nichts.
brew install openldap)slapd.conf mit Definition: database mdb mit
suffix "dc=evil,dc=local"nfsd) — wird mit macOS ausgeliefertslapd, nfsd, /etc/exports)automountd)+auto_master in /etc/auto_master vorhandennfsd läuft auf dem Opfer und exportiert ein VerzeichnisDas 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.
./poc.sh <ATTACKER_IP>
Ersetzen Sie <ATTACKER_IP> durch die IP des Angreifers, wie sie vom
Opfer aus gesehen wird.
sudo automount -vc
ls /System/Volumes/Data/mnt/evil/evil/
cat /System/Volumes/Data/mnt/evil/evil/proof.txt
Die Datei proof.txt ist über den Mount lesbar. Die Mount-Quelle in
der mount-Ausgabe ist 127.0.0.1:<export_dir>:
127.0.0.1:/tmp/nfsroot on /System/Volumes/Data/mnt/evil/evil (nfs, nodev, nosuid, automounted, nobrowse)
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.
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: