autofs-cve-2026-84568

Notes de rétro-ingénierie et PoC fonctionnel pour CVE-2026-84568, une violation de frontière de confiance d'automountd sur macOS permettant des montages depuis localhost ou le nom d'hôte de la victime elle-même.

Pourquoi cette analyse existe

L'avis d'Apple pour CVE-2026-84568 documente l'impact et la version du correctif. Il ne documente pas le mécanisme technique :

• Quelle fonction a été corrigée
• Ce que fait réellement la vérification
• Pourquoi l'exécution de code à distance décrite dans l'avis n'est pas atteignable via les chemins testés ici

Aucune analyse technique publique n'a été trouvée au moment de la rédaction. Ce dépôt comble cette lacune avec une analyse de rétro-ingénierie indépendante de automountd_26.6 et automountd_27, et un PoC fonctionnel pour la violation de frontière de confiance sous-jacente.

Il ne s'agit pas d'une revendication de découverte. Le CVE a été signalé par Mr.Gedik et corrigé par Apple. La contribution ici est l'analyse technique et la reproduction.

Résumé de la vulnérabilité

automountd récupère les cartes automount auprès d'un service d'annuaire configuré (LDAP, NIS, OpenDirectory). Dans la version vulnérable (26.6 et antérieures), automountd ne validait pas si le composant hôte d'une entrée de carte se résolvait vers la machine locale.

Un serveur d'annuaire malveillant pouvait donc servir une entrée de carte dont la source de montage était :

• la chaîne littérale localhost
• le nom d'hôte de la victime lui-même (<hostname>.local)
• n'importe quelle adresse IP locale, y compris 127.0.0.1

La victime montait alors depuis elle-même sur un point de montage contrôlé par l'attaquant.

La version corrigée (26.7 / 27) ajoute une vérification du nom d'hôte dans sym.func.100005bd8 qui rejette les entrées correspondant à l'un des cas ci-dessus.

Contenu de ce dépôt

Rétro-ingénierie

• Diff de désassemblage de sym.func.100005bd8 entre automountd_26.6 et automountd_27 — voir docs/PATCH_DIFF.md
• Identification de la vérification corrigée : strncasecmp contre "localhost", gethostname(), SCDynamicStoreCopyLocalHostName + ".local", et une boucle getifaddrs / getipnodebyaddr énumérant toutes les IP locales
• Trace du champ fstype à travers parse_nfs → mapline_to_mapent → asprintf("%s/mount_%s", "/sbin", fstype) — le champ n'est pas validé avant la construction du chemin du programme
• Analyse du callback SAX du parseur XML de webdavfs_agent — le callback characters utilise __memcpy_chk avec des vérifications explicites de longueur ; pas de débordement
• Analyse de od_process_record_attributes — le parseur d'enregistrements OpenDirectory utilise des API CoreFoundation tout du long ; pas de tampons de taille fixe
• Audit des programmes de montage — mount_nfs, mount_smbfs, mount_url, et tous les bundles NetFSPlugins/* vérifiés pour l'exécution de shell ; aucun trouvé

Voir docs/ANALYSIS.md pour l'analyse complète et docs/ARTIFACTS.md pour les adresses et échantillons de journaux.

Reproduction

• poc.sh — une configuration côté attaquant en un seul fichier. Démarre un serveur LDAP avec une carte malveillante auto_master / auto_evil et une exportation NFS avec un marqueur de preuve d'accès. Lorsque l'automountd de la victime récupère la carte, il monte sa propre exportation NFS sur le chemin contrôlé par l'attaquant.

Ce que ce PoC démontre

• Un serveur LDAP malveillant servant une carte auto_master / auto_evil forgée
• L'automountd de la victime récupérant la carte sur le réseau
• La victime montant sa propre exportation NFS sur un chemin contrôlé par l'attaquant
• La source de montage dans la table de montage du noyau est 127.0.0.1

Ce que ce PoC ne démontre PAS

• L'exécution de code arbitraire
• L'élévation de privilèges
• Un shell sur la victime

L'impact « exécution de code arbitraire avec les privilèges root » de l'avis d'Apple n'est pas atteignable via les chemins testés dans cette analyse. Voir la section « Chemins testés et écartés » dans docs/ANALYSIS.md pour la liste complète.

L'impact démontré est la violation de frontière de confiance elle-même : la victime monte depuis une source qu'elle aurait dû rejeter.

Organisation du dépôt

Quatre fichiers, deux répertoires. Rien d'autre.

Prérequis

Hôte attaquant (macOS)

• Homebrew
• OpenLDAP (brew install openldap)
• slapd.conf définissant : database mdb avec suffix "dc=evil,dc=local"
• Serveur NFS (nfsd) — fourni avec macOS
• Accès root (pour slapd, nfsd, /etc/exports)

Hôte victime

• macOS 26.6 ou antérieur (automountd vulnérable)
• Configuré pour interroger le serveur LDAP de l'attaquant pour les cartes automount
• +auto_master présent dans /etc/auto_master
• nfsd en cours d'exécution sur la victime, exportant un répertoire

La victime a besoin d'un serveur NFS en cours d'exécution pour que le montage réussisse. Le CVE concerne l'acceptation de l'entrée d'hôte local, pas la livraison de l'exportation. Si la victime n'exécute pas nfsd, le montage échoue avec NFS server 127.0.0.1 not responding — ce qui démontre tout de même que automountd a accepté l'entrée.

Utilisation

Attaquant

Remplacez <ATTACKER_IP> par l'IP de l'attaquant telle que vue depuis la victime.

Victime

Résultat attendu

Le fichier proof.txt est lisible à travers le montage. La source de montage dans la sortie de mount est 127.0.0.1:<export_dir> :

La présence de nodev et nosuid reflète les valeurs par défaut du montage NFS du noyau et la gestion des options propre à mount_nfs — elles ne proviennent pas d'automountd. Voir docs/ANALYSIS.md pour la décomposition complète.

Vérification du correctif

Sur un système corrigé (26.7 / 27), la même entrée de carte est rejetée avant toute tentative de montage. Voir docs/PATCH_DIFF.md pour la comparaison de désassemblage de sym.func.100005bd8.

Pour confirmer sur un hôte corrigé :

Attendu : le point de montage n'est pas créé, et aucune entrée n'apparaît dans la sortie de mount. La vérification sym.func.100005bd8 rejette l'entrée lorsque l'hôte est 127.0.0.1, localhost, ou le nom d'hôte local.

L'injection fstype (constatation distincte)

Lors de l'analyse, une faiblesse distincte de défense en profondeur a été trouvée : sym.func.1000086f4 (run_mount_cmd) construit un chemin de programme via asprintf("%s/mount_%s", "/sbin", fstype) sans valider le champ fstype de l'entrée de carte.

Les séquences de traversée de chemin dans fstype atteignent l'appel asprintf :

Sur une installation macOS standard, le chemin résultant ne se résout pas en un exécutable car /sbin/mount_.. n'existe pas. L'injection est réelle mais bloquée par la résolution de chemin. Elle ne deviendrait exploitable que si un chemin inscriptible existait sous /sbin, ou si un lien symbolique de répertoire mount_<X> était créé — ce qui n'est le cas ni l'un ni l'autre sur macOS standard.

Ceci est documenté comme une observation distincte, et non comme partie de CVE-2026-84568. Voir docs/ANALYSIS.md pour les détails.

Crédits

• Découverte originale : Mr.Gedik (@h4ck2s3c) de Turkish Technology, selon l'avis de sécurité Apple pour CVE-2026-84568.
• Analyse indépendante et PoC : jvidhan
• Référence : l'avis d'Apple et le binaire corrigé ont servi de base de comparaison avec la version vulnérable.

Avertissement

Ce dépôt est fourni à des fins de recherche en sécurité défensive et d'éducation uniquement.

• Il est destiné à être utilisé contre des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de tester.
• L'utilisation de cet outil contre des systèmes que vous ne possédez pas ou ne contrôlez pas peut violer les lois locales, nationales ou internationales.
• L'auteur (les auteurs) n'assume(nt) aucune responsabilité pour tout usage abusif ou dommage causé par ce code.
• Le PoC se limite à démontrer une violation de confiance de montage. Il ne parvient pas à l'exécution de code. Toute affirmation d'exécution de code à distance à partir de ce PoC n'est pas étayée par l'analyse incluse.
• Apple, macOS, autofs et automountd sont des marques d'Apple Inc. Ce projet n'est ni affilié à ni approuvé par Apple.

Licence

MIT. Voir LICENSE.