autofs-cve-2026-84568

Note di reverse engineering e PoC funzionante per CVE-2026-84568, una violazione del confine di fiducia di automountd su macOS che consente mount da localhost o dal nome host della vittima stessa.

Perché esiste questo writeup

L'advisory di Apple per CVE-2026-84568 documenta l'impatto e la versione della patch. Non documenta il meccanismo tecnico:

• Quale funzione è stata corretta
• Cosa fa effettivamente il controllo
• Perché l'RCE descritto nell'advisory non è raggiungibile attraverso i percorsi testati qui

Al momento della stesura non è stato trovato alcun writeup tecnico pubblico. Questo repository colma questa lacuna con un'analisi di reverse engineering indipendente di automountd_26.6 e automountd_27, e un PoC funzionante per la sottostante violazione del confine di fiducia.

Questa non è una rivendicazione di scoperta. Il CVE è stato segnalato da Mr.Gedik e corretto da Apple. Il contributo qui è l'analisi tecnica e la riproduzione.

Riepilogo della vulnerabilità

automountd recupera le mappe automount da un servizio di directory configurato (LDAP, NIS, OpenDirectory). Nella versione vulnerabile (26.6 e precedenti), automountd non validava se il componente host di una voce di mappa si risolvesse alla macchina locale.

Un server di directory malevolo poteva quindi servire una voce di mappa la cui sorgente di mount era:

• la stringa letterale localhost
• il nome host della vittima stessa (<hostname>.local)
• qualsiasi indirizzo IP locale, incluso 127.0.0.1

La vittima avrebbe quindi montato da se stessa in un punto di mount controllato dall'attaccante.

La versione corretta (26.7 / 27) aggiunge un controllo del nome host in sym.func.100005bd8 che rifiuta le voci che corrispondono a una qualsiasi delle precedenti.

Cosa contiene questo repository

Reverse engineering

• Diff del disassemblaggio di sym.func.100005bd8 tra automountd_26.6 e automountd_27 — vedi docs/PATCH_DIFF.md
• Identificazione del controllo corretto: strncasecmp contro "localhost", gethostname(), SCDynamicStoreCopyLocalHostName + ".local", e un ciclo getifaddrs / getipnodebyaddr che enumera tutti gli IP locali
• Traccia del campo fstype attraverso parse_nfs → mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) — il campo non viene validato prima di costruire il percorso del programma
• Analisi del callback SAX del parser XML di webdavfs_agent — il callback characters usa __memcpy_chk con controlli espliciti di lunghezza; nessun overflow
• Analisi di od_process_record_attributes — il parser dei record OpenDirectory usa le API CoreFoundation ovunque; nessun buffer a dimensione fissa
• Audit dei programmi di mount — mount_nfs, mount_smbfs, mount_url, e tutti i bundle NetFSPlugins/* controllati per l'esecuzione di shell; nessuno trovato

Vedi docs/ANALYSIS.md per il writeup completo e docs/ARTIFACTS.md per gli indirizzi e i campioni di log.

Riproduzione

• poc.sh — un setup lato attaccante in un singolo file. Avvia un server LDAP con una mappa auto_master / auto_evil malevola e un export NFS con un marcatore di prova di accesso. Quando l'automountd della vittima recupera la mappa, monta il proprio export NFS nel percorso controllato dall'attaccante.

Cosa dimostra questo PoC

• Un server LDAP malevolo che serve una mappa auto_master / auto_evil artigianale
• L'automountd della vittima che recupera la mappa attraverso la rete
• La vittima che monta il proprio export NFS in un percorso controllato dall'attaccante
• La sorgente di mount nella tabella dei mount del kernel è 127.0.0.1

Cosa NON dimostra questo PoC

• Esecuzione di codice arbitrario
• Escalation di privilegi
• Una shell sulla vittima

L'impatto "esecuzione di codice arbitrario con privilegi di root" nell'advisory di Apple non è raggiungibile attraverso i percorsi testati in questa analisi. Vedi la sezione "Percorsi testati ed esclusi" in docs/ANALYSIS.md per l'elenco completo.

L'impatto dimostrato è la violazione del confine di fiducia stessa: la vittima monta da una sorgente che avrebbe dovuto rifiutare.

Struttura del repository

Quattro file, due directory. Nient'altro.

Requisiti

Host attaccante (macOS)

• Homebrew
• OpenLDAP (brew install openldap)
• slapd.conf che definisce: database mdb con suffix "dc=evil,dc=local"
• Server NFS (nfsd) — incluso in macOS
• Accesso root (per slapd, nfsd, /etc/exports)

Host vittima

• macOS 26.6 o precedente (automountd vulnerabile)
• Configurato per interrogare il server LDAP dell'attaccante per le mappe automount
• +auto_master presente in /etc/auto_master
• nfsd in esecuzione sulla vittima, che esporta una directory

La vittima necessita di un server NFS in esecuzione perché il mount riesca. Il CVE riguarda l'accettazione della voce dell'host locale, non la distribuzione dell'export. Se la vittima non esegue nfsd, il mount fallisce con NFS server 127.0.0.1 not responding — il che comunque dimostra che automountd ha accettato la voce.

Utilizzo

Attaccante

Sostituisci <ATTACKER_IP> con l'IP dell'attaccante come visto dalla vittima.

Vittima

Risultato atteso

Il file proof.txt è leggibile attraverso il mount. La sorgente di mount nell'output di mount è 127.0.0.1:<export_dir>:

La presenza di nodev e nosuid riflette le impostazioni predefinite di mount NFS del kernel e la gestione delle opzioni di mount_nfs stesso — non provengono da automountd. Vedi docs/ANALYSIS.md per la ripartizione completa.

Verifica della patch

Su un sistema corretto (26.7 / 27), la stessa voce di mappa viene rifiutata prima di qualsiasi tentativo di mount. Vedi docs/PATCH_DIFF.md per il confronto del disassemblaggio di sym.func.100005bd8.

Per confermare su un host corretto:

Atteso: il punto di mount non viene creato e nessuna voce appare nell'output di mount. Il controllo sym.func.100005bd8 rifiuta la voce quando l'host è 127.0.0.1, localhost, o il nome host locale.

L'iniezione di fstype (scoperta separata)

Durante l'analisi, è stata trovata una debolezza separata di difesa in profondità: sym.func.1000086f4 (run_mount_cmd) costruisce un percorso di programma tramite asprintf("%s/mount_%s", "/sbin", fstype) senza validare il campo fstype dalla voce di mappa.

Le sequenze di path traversal in fstype raggiungono la chiamata asprintf:

Su un'installazione standard di macOS, il percorso risultante non si risolve in un eseguibile perché /sbin/mount_.. non esiste. L'iniezione è reale ma bloccata dalla risoluzione del percorso. Diventerebbe sfruttabile solo se esistesse un percorso scrivibile sotto /sbin, o se fosse creato un symlink di directory mount_<X> — nessuna delle due condizioni vale su macOS standard.

Questo è documentato come osservazione separata, non come parte di CVE-2026-84568. Vedi docs/ANALYSIS.md per i dettagli.

Crediti

• Scoperta originale: Mr.Gedik (@h4ck2s3c) di Turkish Technology, secondo l'advisory di sicurezza Apple per CVE-2026-84568.
• Analisi indipendente e PoC: jvidhan
• Riferimento: l'advisory di Apple e il binario corretto sono serviti come base di confronto con la versione vulnerabile.

Disclaimer

Questo repository è fornito solo per ricerca di sicurezza difensiva e istruzione.

• È destinato all'uso contro sistemi di tua proprietà o per i quali hai esplicito permesso scritto di testare.
• L'uso di questo strumento contro sistemi che non possiedi o controlli può violare leggi locali, nazionali o internazionali.
• Gli autori non si assumono alcuna responsabilità per qualsiasi uso improprio o danno causato da questo codice.
• Il PoC è limitato a dimostrare una violazione della fiducia di mount. Non raggiunge l'esecuzione di codice. Qualsiasi affermazione di RCE da questo PoC non è supportata dall'analisi inclusa.
• Apple, macOS, autofs e automountd sono marchi di Apple Inc. Questo progetto non è affiliato né approvato da Apple.

Licenza

MIT. Vedi LICENSE.