CVE-2026-43499 sur Amazon Fire TV Stick 3rd Gen (sheldonp)

Enchaînement d'une élévation de privilèges du noyau Linux vers un downgrade du preloader et un déverrouillage du bootloader.

Vue d'ensemble

Ce dépôt documente ma reproduction autorisée de la chaîne d'exploitation CVE-2026-43499 sur un Amazon Fire TV Stick 3rd Gen (sheldonp). La chaîne utilisait un root noyau temporaire pour exécuter un downgrade contrôlé du preloader, puis utilisait le workflow Kamakiri BootROM existant pour atteindre un fastboot déverrouillé et terminer le déverrouillage du bootloader.

Il s'agit d'une reproduction et d'une étude de cas spécifique à un appareil. Je n'ai pas découvert CVE-2026-43499, ni créé l'exploit original IonStack/GhostLock, ni développé Kamakiri. Les chercheurs et développeurs en amont sont crédités ci-dessous.

[!IMPORTANT] Ce document est un compte rendu technique, pas un guide de root universel. La compatibilité de build est importante, le root temporaire n'est pas un root persistant, et des erreurs impliquant le Preloader, LK, TEE ou les partitions protégées par dm-verity peuvent bricker définitivement l'appareil.

Compte rendu de reproduction

La chaîne de bout en bout a été complétée le 12 septembre 2026. Ce dépôt consigne l'appareil et les versions logicielles testés, les archives exactes utilisées, leurs hachages SHA-256, et les preuves originales capturées durant le processus.

Périmètre

Hors périmètre : découverte de vulnérabilité, nouvelle implémentation d'exploit, exploitation à distance, root persistant, ou prise en charge d'appareils autres que l'unité sheldonp testée. Aucune ROM personnalisée n'a été installée durant cette reproduction.

Archives de reproduction

Voici les archives ZIP exactes utilisées durant cette reproduction. Les archives ne sont pas redistribuées dans ce dépôt ; leurs hachages SHA-256 sont consignés afin que des copies obtenues indépendamment puissent être comparées aux fichiers utilisés dans cette étude de cas.

Ces hachages identifient les copies utilisées dans cette étude de cas ; les lecteurs doivent néanmoins comparer leurs téléchargements avec les sources amont originales et examiner les licences tierces applicables.

Contexte technique

CVE-2026-43499, également connu sous le nom de GhostLock, est un use-after-free dans le chemin futex/rtmutex d'héritage de priorité du noyau Linux. Lors du rollback du proxy-lock, remove_waiter() opérait sur current au lieu de la tâche stockée dans waiter->task. En conséquence, le véritable waiter pouvait retourner en espace utilisateur avec pi_blocked_on référençant encore un rt_mutex_waiter dans une frame de pile noyau libérée.

La recherche originale IonStack transforme cette référence de pile pendante en une primitive d'élévation de privilèges locale. R0rt1z2 a adapté la technique au Fire TV Stick 3rd Gen et au Fire TV Stick Lite (sheldonp/sheldon) fonctionnant sous Fire OS 7 sur un noyau 4.4.

La distinction clé dans cette étude de cas est que CVE-2026-43499 ne déverrouille pas directement le bootloader. Il fournit un accès temporaire au niveau du noyau. Cet accès de courte durée rend possible le downgrade contrôlé du preloader requis avant que l'ancienne chaîne Kamakiri BootROM puisse s'exécuter.

Chaîne d'exploitation

flowchart LR
    A[Fire OS 7 on sheldonp] --> B[CVE-2026-43499 / GhostLock]
    B --> C[Temporary root shell]
    C --> D[Controlled preloader downgrade]
    D --> E[Expected non-booting transition state]
    E --> F[Kamakiri BootROM stage]
    F --> G[Unlocked fastboot]
    G --> H[Bootloader unlocked]

La chaîne franchit deux frontières de sécurité distinctes :

1. Frontière du noyau : un processus local non privilégié obtient un contexte root temporaire via GhostLock.
2. Frontière de la chaîne de démarrage : le root temporaire prépare l'appareil pour un chemin de déverrouillage connu basé sur le BootROM en restaurant un preloader compatible.

Méthodologie

1. Établir la ligne de base

Avant de modifier l'appareil, j'ai identifié le nom de code matériel et consigné les versions de Fire OS, build, bootloader et noyau via ADB.

adb devices -l
adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.fingerprint
adb shell getprop ro.bootloader
adb shell uname -a
adb shell id

La ligne de base résultante était sheldonp / AFTSSS, Fire OS PS7716.5666N, incrémental 0036005356164, Android 9, et noyau 4.4.162+. Le numéro de série est délibérément omis.

2. Obtenir un root temporaire avec GhostLock

J'ai connecté le Fire TV en USB avec le débogage ADB activé et utilisé GhostLock 1.1.0, le paquet sheldon/sheldonp publié avec le guide XDA de R0rt1z2. Le lanceur spécifique à l'appareil redémarre le Fire TV pour démarrer depuis un état neuf, déploie l'exploit, et réessaie lorsque nécessaire.

Une exploitation réussie crée un environnement root temporaire. J'ai vérifié le contexte de sécurité depuis un shell ADB plutôt que de considérer la seule fin du script comme preuve :

adb shell
su
id

Le contexte root est éphémère et est perdu au redémarrage. Ce comportement est important : cette étape est une primitive d'activation pour le downgrade, pas le mécanisme de persistance final ni le déverrouillage du bootloader lui-même.

L'exécution réussie a montré uid=0, a changé SELinux en permissive pour l'environnement temporaire, a monté le su temporaire, et a désactivé les paquets OTA de Fire OS gérés par l'outil.

La trace complète de l'exploit GhostLock est conservée comme preuve à l'appui.

3. Downgrader le preloader

Avec le root temporaire disponible, j'ai utilisé le workflow de downgrade dédié du paquet plutôt que d'écrire manuellement les partitions de firmware. Cela a restauré un preloader compatible avec le chemin Kamakiri existant.

Après le downgrade, le Fire TV a intentionnellement cessé de démarrer sous Fire OS. Dans ce workflow spécifique, cet état de non-démarrage est le passage attendu entre l'étape noyau actif et l'étape USB BootROM. Il ne doit pas être confondu avec la preuve qu'un flash échoué arbitraire est récupérable.

[!CAUTION] N'effacez jamais le Preloader. N'improvisez pas d'écritures vers LK, TEE, Preloader, boot, recovery, system, vendor, ou d'autres partitions protégées. Les guides en amont avertissent que des dommages au firmware critique peuvent causer un hard brick permanent car un chemin de récupération fonctionnel peut ne plus rester disponible.

4. Exécuter la chaîne Kamakiri BootROM

Le workflow Kamakiri utilisé pour cet appareil était pris en charge et documenté pour Linux. J'ai donc démarré une session Ubuntu Live et effectué le workflow complet de déverrouillage là-bas, y compris l'étape USB BootROM de bas niveau, sans installer Ubuntu sur l'hôte. Je n'ai pas testé cette étape sous Windows ou macOS.

En utilisant le paquet Kamakiri sheldon/sheldonp référencé par le guide de déverrouillage, le processus était :

1. Préparer Python, PySerial, PyUSB, ADB, Fastboot, et l'environnement USB requis par Kamakiri.
2. Lancer bootrom-step.sh et connecter le Fire TV éteint en USB.
3. Laisser l'étape BootROM se terminer et faire passer l'appareil dans l'environnement fastboot modifié.
4. Exécuter fastboot-step.sh pour terminer le workflow de déverrouillage.
5. Redémarrer et vérifier que le chemin de démarrage déverrouillé attendu était disponible.

Kamakiri a détecté l'unité comme sheldonp, a complété le downgrade RPMB, a flashé les composants TZ/LK requis par la chaîne, a injecté le microloader, et a forcé l'appareil dans son mode fastboot piraté.

Les hachages des archives et la version d'Ubuntu sont consignés ci-dessus. Les lecteurs doivent utiliser les guides amont liés pour des instructions spécifiques à une version plutôt que de supposer que ces étapes de haut niveau s'appliquent à un autre build.

5. Valider le résultat

J'ai traité les éléments suivants comme des jalons distincts et capturé une preuve pour chacun :

6. Préserver Fire OS et ajuster l'état post-déverrouillage

Mon objectif était de conserver le Fire OS d'origine plutôt que d'installer immédiatement une ROM personnalisée. Dans TWRP, j'ai évité d'effacer les données ou de remplacer le système d'exploitation, puis j'ai redémarré dans l'installation Fire OS existante. TWRP et le chemin de démarrage déverrouillé sont restés disponibles tandis que l'environnement utilisateur d'origine était préservé.

Après être revenu sous Fire OS, j'ai maintenu les mises à jour OTA désactivées afin qu'Amazon ne puisse pas déplacer silencieusement l'appareil vers un build qui modifiait l'exploit ou la chaîne de démarrage récupérée. J'ai également désactivé le composant de protection des applications système d'Amazon communément appelé dans l'outillage de la communauté Fire TV ARCUS. Cela modifie le comportement de blocage d'applications au niveau de l'OS d'Amazon ; cela ne contourne pas Widevine, les vérifications d'abonnement, ou l'application des licences implémentée dans les applications individuelles.

Étapes suivantes optionnelles

Un bootloader déverrouillé et TWRP permettent également d'installer des logiciels personnalisés compatibles. Une option communautaire pour cette famille d'appareils est LineageOS 20 basé sur Android 13. D'autres ROMs compatibles, workflows de récupération, ou configurations de root persistant peuvent également être possibles.

Ces alternatives ne faisaient pas partie de cette reproduction. Elles doivent être traitées comme des procédures distinctes avec leurs propres considérations de firmware, TZ, effacement de données, DRM, mémoire, et récupération.

Observations

• Une connexion ADB USB filaire est préférable car les tentatives d'exploit peuvent redémarrer la cible et interrompre l'ADB sans fil.
• La fiabilité de l'exploit dépend de la cible et du build. Une nouvelle tentative ou un redémarrage n'est pas la preuve qu'un appareil n'est pas pris en charge, mais les offsets et la compatibilité de build doivent tout de même être vérifiés.
• L'étape de root temporaire et l'étape Kamakiri résolvent des problèmes différents et doivent être documentées indépendamment.
• L'état de non-démarrage attendu après le downgrade n'a de sens que lorsque l'outil de downgrade signale un succès et que le workflow pris en charge exact est suivi.
• Une sortie de script réussie est une preuve plus faible que l'état capturé de l'appareil, l'identité root, et la vérification fastboot/recovery.
• Le déverrouillage du bootloader n'a pas nécessité de remplacer Fire OS ; conserver le Fire OS d'origine était un choix délibéré après le déverrouillage.
• La désactivation d'ARCUS affecte la couche de blocage d'applications d'Amazon, tandis que le DRM des applications et les licences de contenu restent des préoccupations distinctes.

Impact sur la sécurité

Sur un build Fire OS vulnérable et pris en charge, du code déjà en cours d'exécution localement sur l'appareil peut exploiter la faille du noyau pour obtenir un contexte root temporaire. Dans ce laboratoire, cet accès a élargi la surface d'attaque au-delà du système d'exploitation en cours d'exécution : il a permis un downgrade de firmware qui a réintroduit une condition de chaîne de démarrage exploitable par un ancien exploit BootROM.

Cette chaîne illustre pourquoi la sécurité d'un appareil dépend de plus que du patch d'une seule couche. Une élévation de privilèges du noyau peut devenir un pont vers une persistance de plus bas niveau ou une compromission de la chaîne de démarrage lorsque des logiciels privilégiés peuvent modifier l'état du firmware critique pour la sécurité.

Structure du dépôt

.
├── README.md              # Case study and methodology
├── LICENSE                # CC BY 4.0 for original documentation and media
├── images/
│   ├── README.md          # Evidence index and redaction guidance
│   └── evidence/          # Sanitized screenshots and photographs
└── references/
    └── README.md          # Source ledger and artifact guidance

Ce dépôt ne redistribue pas les archives ZIP tierces. Obtenez-les à partir des guides XDA originaux, examinez leurs conditions applicables, et comparez leurs hachages avec les valeurs consignées ci-dessus.

Crédits

• NebuSec / CyberMeowfia — découverte et recherche originale IonStack/GhostLock et implémentation de l'exploit pour CVE-2026-43499.
• R0rt1z2 — adaptation Fire OS, la branche GhostLock 4.4, et le guide de root temporaire et de downgrade sheldon/sheldonp.
• IonStackQuest3 — premier port public de GhostLock pour les noyaux Linux 5.10, crédité par le projet Fire OS en aval.
• Contributeurs Amonet/Kamakiri, dont xyz, k4y0z, Rortiz2, t0x1cSH, et les testeurs crédités dans le fil de déverrouillage original — travail sur BootROM, fastboot, recovery, et déverrouillage spécifique à l'appareil.

Ma contribution est la reproduction indépendante, le compte rendu d'exécution spécifique à l'appareil, l'analyse de la façon dont les étapes se connectent, et les preuves originales publiées dans ce dépôt.

Références

Le registre de sources maintenu se trouve dans references/README.md. Les sources principales incluent :

• Enregistrement CVE-2026-43499
• NebuSec : entrée de vulnérabilité GhostLock
• NebuSec : IonStack Part III — exploitation Android
• CyberMeowfia : source IonStack/CVE-2026-43499
• R0rt1z2/GhostLock, branche 4.4
• XDA : root temporaire et downgrade du preloader pour sheldon/sheldonp
• Source Amonet/Kamakiri
• XDA : guide de déverrouillage du bootloader, TWRP, et unbrick pour sheldon/sheldonp
• Correctif du noyau Linux pour remove_waiter()

Avis d'utilisation responsable

Ce matériel est fourni à des fins éducatives et de recherche en sécurité autorisée sur du matériel que vous possédez ou êtes explicitement autorisé à tester. Il est fourni sans garantie. Vous êtes responsable de la conformité légale, de la perte de données, de la perturbation de service, et des dommages matériels résultant de vos actions.

Licence

Le texte et les images originaux créés pour ce dépôt sont sous licence Creative Commons Attribution 4.0 International License.

Les outils tiers, le code d'exploit, le firmware, les citations, les captures d'écran, les marques, et les matériaux référencés restent soumis à leur paternité et licences respectives. L'inclusion d'un lien ou d'un crédit ne relicencie pas ce matériel sous CC BY 4.0.