CVE-2026-28912 — Notes de rétro-ingénierie et reproduction

Rétro-ingénierie indépendante du bug de suivi de lien symbolique de macOS PackageKit (CVE-2026-28912), accompagnée d'un PoC fonctionnel qui démontre que l'installateur écrit un fichier contrôlé par l'attaquant en tant que root via un lien symbolique de répertoire dans le chemin de destination de l'installation.

Le bug est un parcours de chemin non synchronisé dans la logique de reliaison de fichiers de PKCoreShove. Un .pkg malveillant peut déclarer un chemin de destination dans un répertoire non privilégié, placer un lien symbolique de répertoire sur l'un des composants du chemin pointant vers un emplacement privilégié, et amener l'installateur — s'exécutant en tant que root — à écrire dans la cible du lien symbolique. Le correctif 26.6 d'Apple ajoute _PKSIPOpenPathSafely qui parcourt chaque composant du chemin avec O_NOFOLLOW et rejette tout lien symbolique.

---

Le CVE en un coup d'œil

Champ	Valeur
CVE	CVE-2026-28912
Composant	PackageKit (PKCoreShove, PKBundleComponent)
Affecté	macOS Tahoe 26.5 et antérieurs
Corrigé dans	macOS Tahoe 26.6
Impact de l'avis	« Une app peut être en mesure d'obtenir les privilèges root. »
CVSS v3.1	7.8 (Élevé)
Signalé par	Découvreurs originaux selon l'avis d'Apple

---

Pourquoi cette analyse existe

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

• Quelle fonction de PackageKit suit le lien symbolique
• Pourquoi l'installateur parcourt le chemin de destination sans vérifier chaque composant
• Quelle fonction a été ajoutée dans 26.6 pour fermer le bug
• Pourquoi le correctif insère un parcours O_NOFOLLOW à exactement ce point
• Pourquoi le PoC doit utiliser un lien symbolique de répertoire plutôt qu'un lien symbolique de fichier
• Pourquoi un lien symbolique au niveau du fichier à la destination est remplacé plutôt que suivi

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 PackageKit entre 26.4 et 26.6, et un PoC fonctionnel qui démontre la primitive en direct.

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

---

Résumé de la vulnérabilité

PKCoreShove _relinkFile:dest: dans macOS 26.4 parcourt le chemin de destination composant par composant lors de la création d'un fichier :

; 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 retourne 0 (faux) lorsque le processus appelant ne peut pas modifier les fichiers SIP — le cas normal pour une installation initiée par l'utilisateur. Cela désactive RENAME_NOFOLLOW_ANY, donc le renommage suit tout lien symbolique dans le chemin de destination.

Le correctif 26.6 ajoute _PKSIPOpenPathSafely, appelé depuis PKBundleComponent initWithBundleAtPath:relativeToDestination::

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

_PKSIPOpenPathSafely :

1. Ouvre chaque composant du chemin avec O_NOFOLLOW (0x4)
2. Détecte les liens symboliques via S_IFLNK (0xa000 dans st_mode)
3. Vérifie la protection SIP via _PKSIPFullyProtected
4. Lit SF_RESTRICTED via fgetattrlist
5. Utilise close_drop_np pour abandonner l'extension sandbox lors du nettoyage

Tout composant qui est un lien symbolique pointant en dehors du chemin prévu est rejeté avec EPERM ou ELOOP, et l'installation échoue.

---

Ce que contient ce dépôt

Rétro-ingénierie

• Diff de désassemblage de PKCoreShove _relinkFile:dest: et _linkResolutionProhibitted entre 26.4 et 26.6
• Identification du champ vulnérable : _linkResolutionProhibitted retournant 0 pour les processus ne modifiant pas SIP
• Identification du correctif : _PKSIPOpenPathSafely ajouté à PKBundleComponent, parcours O_NOFOLLOW par composant
• Analyse des appels système : l'installateur utilise renamex_np avec RENAME_NOFOLLOW_ANY = 0x10 uniquement lorsque l'appelant peut modifier les fichiers SIP
• Confirmation à l'exécution : fs_usage montre l'installateur faisant stat/listxattr sur la cible du lien symbolique et écrivant à travers le lien symbolique de répertoire

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

Reproduction

• link.sh — un PoC autonome en un seul fichier :

  1. Crée un lien symbolique de répertoire à $HOME/cve-poc/target → $HOME/cve-poc/real
  2. Construit un .pkg dont la charge utile déclare un fichier à $HOME/cve-poc/target/poc.txt
  3. L'installe avec sudo installer
  4. Vérifie que le fichier a atterri dans $HOME/cve-poc/real/poc.txt — avec la propriété root:wheel

---

Ce que ce PoC démontre

• Une charge utile .pkg déclarant un fichier sous un répertoire non privilégié
• L'installateur suivant un lien symbolique de répertoire à ce chemin
• Un fichier appartenant à root créé en dehors de la destination déclarée
• Capture en direct de l'écriture via fs_usage

Ce que ce PoC ne démontre PAS

• Un lien symbolique au niveau du fichier à la destination. Les liens symboliques de fichier sont remplacés par renamex_np, pas suivis — l'écriture doit passer par un lien symbolique de répertoire dans le chemin.
• L'exécution de code, l'élévation de privilèges ou un shell sur la victime
• L'armement : le PoC utilise par défaut $HOME/cve-poc/real/, pas /etc/sudoers.d/ ou /Library/LaunchDaemons/

L'impact démontré est la primitive de suivi de lien symbolique — le comportement exact que le correctif 26.6 ferme.

---

Prérequis

Hôte cible (victime)

• macOS Tahoe 26.5 ou antérieur (PackageKit vulnérable)
• pkgbuild, installer, fs_usage
• Root (pour l'installateur)

Aucun hôte attaquant séparé nécessaire

Le PoC s'exécute entièrement sur la cible. Le lien symbolique et la charge utile sont tous deux créés localement. Cela garde le PoC autonome et reproductible sans aucune configuration réseau.

---

Utilisation

chmod +x link.sh
./link.sh

Réglage optionnel via des variables d'environnement :

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

CONTENT définit le contenu écrit à travers le lien symbolique. Par défaut, il s'agit de hello.

Sortie attendue

[*] 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

Vérification du correctif

Sur un système corrigé (26.6), le même PoC échoue :

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

Voir docs/PATCH_DIFF.md pour la comparaison de désassemblage.

---

Pièges des .pkg (pour la reproductibilité)

Deux détails du PoC ont été découverts lors du développement et sont documentés ici afin que d'autres construisant des outils similaires ne les rencontrent pas :