CVE-2026-43499 su Amazon Fire TV Stick 3ª Gen (sheldonp)

Concatenare un'escalation di privilegi del kernel Linux in un downgrade del preloader e nello sblocco del bootloader.

Panoramica

Questo repository documenta la mia riproduzione autorizzata della catena di exploit CVE-2026-43499 su un Amazon Fire TV Stick 3ª Gen (sheldonp). La catena ha utilizzato un root temporaneo a livello di kernel per eseguire un downgrade controllato del preloader, quindi ha utilizzato il flusso di lavoro Kamakiri BootROM esistente per raggiungere il fastboot sbloccato e completare lo sblocco del bootloader.

Questa è una riproduzione e un caso di studio specifico per il dispositivo. Non ho scoperto CVE-2026-43499, non ho creato l'exploit originale IonStack/GhostLock, né ho sviluppato Kamakiri. I ricercatori e gli sviluppatori upstream sono accreditati di seguito.

[!IMPORTANT] Questo write-up è un resoconto tecnico, non una guida universale al rooting. La compatibilità della build è importante, il root temporaneo non è un root persistente, e errori che coinvolgono Preloader, LK, TEE o partizioni protette da dm-verity possono brickare permanentemente il dispositivo.

Resoconto della riproduzione

La catena end-to-end è stata completata il 12 settembre 2026. Questo repository registra il dispositivo testato e le versioni software, gli archivi esatti utilizzati, i loro hash SHA-256 e le prove originali catturate durante il processo.

Ambito

Fuori ambito: scoperta della vulnerabilità, una nuova implementazione dell'exploit, sfruttamento remoto, root persistente o supporto per dispositivi diversi dall'unità sheldonp testata. Nessuna ROM personalizzata è stata installata durante questa riproduzione.

Archivi della riproduzione

I seguenti sono gli archivi ZIP esatti utilizzati durante questa riproduzione. Gli archivi non sono ridistribuiti in questo repository; i loro hash SHA-256 sono registrati in modo che copie ottenute indipendentemente possano essere confrontate con i file utilizzati in questo caso di studio.

Questi hash identificano le copie utilizzate in questo caso di studio; i lettori dovrebbero comunque confrontare i propri download con le fonti upstream originali e rivedere le licenze di terze parti applicabili.

Contesto tecnico

CVE-2026-43499, noto anche come GhostLock, è una use-after-free nel percorso futex/rtmutex di priority-inheritance del kernel Linux. Durante il rollback del proxy-lock, remove_waiter() operava su current invece che sul task memorizzato in waiter->task. Di conseguenza, il waiter effettivo poteva tornare in userspace con pi_blocked_on che faceva ancora riferimento a un rt_mutex_waiter in un frame dello stack del kernel rilasciato.

La ricerca originale IonStack trasforma quel riferimento pendente allo stack in una primitiva di escalation di privilegi locale. R0rt1z2 ha adattato la tecnica al Fire TV Stick 3ª Gen e al Fire TV Stick Lite (sheldonp/sheldon) con Fire OS 7 su un kernel 4.4.

La distinzione chiave in questo caso di studio è che CVE-2026-43499 non sblocca direttamente il bootloader. Fornisce un accesso temporaneo a livello di kernel. Quell'accesso di breve durata rende possibile eseguire il downgrade controllato del preloader richiesto prima che la catena Kamakiri BootROM più vecchia possa essere eseguita.

Catena di exploit

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 catena attraversa due confini di sicurezza separati:

1. Confine del kernel: un processo locale non privilegiato ottiene un contesto root temporaneo tramite GhostLock.
2. Confine della catena di boot: il root temporaneo prepara il dispositivo per un percorso di sblocco noto basato su BootROM ripristinando un preloader compatibile.

Metodologia

1. Stabilire la baseline

Prima di modificare il dispositivo, ho identificato il nome in codice dell'hardware e registrato le versioni di Fire OS, build, bootloader e kernel tramite 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 baseline risultante era sheldonp / AFTSSS, Fire OS PS7716.5666N, incrementale 0036005356164, Android 9 e kernel 4.4.162+. Il numero di serie è deliberatamente omesso.

2. Ottenere il root temporaneo con GhostLock

Ho collegato il Fire TV via USB con il debug ADB abilitato e ho utilizzato GhostLock 1.1.0, il pacchetto sheldon/sheldonp pubblicato con la guida XDA di R0rt1z2. Il launcher specifico per il dispositivo riavvia il Fire TV per partire da uno stato pulito, distribuisce l'exploit e riprova quando necessario.

Un'exploit riuscita crea un ambiente root temporaneo. Ho verificato il contesto di sicurezza da una shell ADB invece di considerare il solo completamento dello script come prova:

adb shell
su
id

Il contesto root è effimero e viene perso al riavvio. Questo comportamento è importante: questa fase è una primitiva abilitante per il downgrade, non il meccanismo di persistenza finale né lo sblocco del bootloader stesso.

L'esecuzione riuscita ha mostrato uid=0, ha impostato SELinux in modalità permissiva per l'ambiente temporaneo, ha montato il su temporaneo e ha disabilitato i pacchetti OTA di Fire OS gestiti dallo strumento.

La traccia completa dell'exploit GhostLock è conservata come prova di supporto.

3. Eseguire il downgrade del preloader

Con il root temporaneo disponibile, ho utilizzato il flusso di lavoro dedicato al downgrade del pacchetto invece di scrivere manualmente le partizioni del firmware. Questo ha ripristinato un preloader compatibile con il percorso Kamakiri esistente.

Dopo il downgrade, il Fire TV ha intenzionalmente smesso di avviarsi in Fire OS. In questo specifico flusso di lavoro, quello stato di non avvio è il passaggio previsto tra la fase del kernel attivo e la fase USB BootROM. Non deve essere confuso con la prova che un flash fallito arbitrario sia recuperabile.

[!CAUTION] Non cancellare mai il Preloader. Non improvvisare scritture su LK, TEE, Preloader, boot, recovery, system, vendor o altre partizioni protette. Le guide upstream avvertono che danni al firmware critico possono causare un hard brick permanente perché un percorso di ripristino funzionante potrebbe non rimanere disponibile.

4. Eseguire la catena Kamakiri BootROM

Il flusso di lavoro Kamakiri utilizzato per questo dispositivo era supportato e documentato per Linux. Ho quindi avviato una sessione Ubuntu Live ed eseguito l'intero flusso di sblocco lì, inclusa la fase USB BootROM di basso livello, senza installare Ubuntu sull'host. Non ho testato questa fase su Windows o macOS.

Utilizzando il pacchetto Kamakiri sheldon/sheldonp referenziato dalla guida allo sblocco, il processo è stato:

1. Preparare Python, PySerial, PyUSB, ADB, Fastboot e l'ambiente USB richiesto da Kamakiri.
2. Avviare bootrom-step.sh e collegare il Fire TV spento via USB.
3. Consentire alla fase BootROM di completarsi e far passare il dispositivo all'ambiente fastboot modificato.
4. Eseguire fastboot-step.sh per completare il flusso di sblocco.
5. Riavviare e verificare che il percorso di boot sbloccato previsto fosse disponibile.

Kamakiri ha rilevato l'unità come sheldonp, ha completato il downgrade RPMB, ha flashato i componenti TZ/LK richiesti dalla catena, ha iniettato il microloader e ha forzato il dispositivo nella sua modalità fastboot modificata.

Gli hash degli archivi e la release di Ubuntu sono registrati sopra. I lettori dovrebbero utilizzare le guide upstream collegate per istruzioni specifiche per versione invece di presumere che questi passaggi di alto livello si applichino a un'altra build.

5. Convalidare il risultato

Ho trattato i seguenti come traguardi separati e ho catturato prove per ciascuno di essi:

6. Preservare Fire OS e regolare lo stato post-sblocco

Il mio obiettivo era conservare Fire OS stock invece di installare immediatamente una ROM personalizzata. In TWRP ho evitato di cancellare i dati o sostituire il sistema operativo, quindi ho riavviato nell'installazione Fire OS esistente. TWRP e il percorso di boot sbloccato sono rimasti disponibili mentre l'ambiente utente stock veniva preservato.

Dopo essere tornato a Fire OS, ho mantenuto gli aggiornamenti OTA disabilitati in modo che Amazon non potesse spostare silenziosamente il dispositivo su una build che modificava l'exploit o alterava la catena di boot ripristinata. Ho anche disabilitato il componente di protezione delle app di sistema Amazon comunemente indicato nel tooling della community Fire TV come ARCUS. Questo modifica il comportamento di blocco delle app a livello di OS di Amazon; non aggira Widevine, i controlli di abbonamento o l'applicazione delle licenze implementata all'interno delle singole applicazioni.

Passaggi successivi opzionali

Un bootloader sbloccato e TWRP rendono anche possibile installare software personalizzato compatibile. Un'opzione della community per questa famiglia di dispositivi è LineageOS 20 basato su Android 13. Altre ROM compatibili, flussi di lavoro di recovery o configurazioni di root persistente potrebbero essere ugualmente possibili.

Queste alternative non facevano parte di questa riproduzione. Dovrebbero essere trattate come procedure separate con le proprie considerazioni su firmware, TZ, cancellazione dati, DRM, memoria e recovery.

Osservazioni

• Una connessione ADB USB cablata è preferibile perché i tentativi dell'exploit possono riavviare il target e interrompere l'ADB wireless.
• L'affidabilità dell'exploit dipende dal target e dalla build. Un nuovo tentativo o un riavvio non è prova che un dispositivo non sia supportato, ma gli offset e la compatibilità della build devono comunque essere verificati.
• La fase di root temporaneo e la fase Kamakiri risolvono problemi diversi e dovrebbero essere documentate indipendentemente.
• Lo stato di non avvio previsto dopo il downgrade è significativo solo quando lo strumento di downgrade segnala successo e si sta seguendo l'esatto flusso di lavoro supportato.
• Un'uscita riuscita dello script è una prova più debole rispetto allo stato catturato del dispositivo, all'identità root e alla verifica fastboot/recovery.
• Sbloccare il bootloader non ha richiesto di sostituire Fire OS; mantenere Fire OS stock è stata una scelta deliberata post-sblocco.
• Disabilitare ARCUS influisce sul livello di blocco delle app di Amazon, mentre il DRM delle applicazioni e le licenze dei contenuti rimangono questioni separate.

Impatto sulla sicurezza

Su una build Fire OS vulnerabile e supportata, codice già in esecuzione localmente sul dispositivo può sfruttare il difetto del kernel per ottenere un contesto root temporaneo. In questo laboratorio, quell'accesso ha ampliato la superficie di attacco oltre il sistema operativo in esecuzione: ha abilitato un downgrade del firmware che ha reintrodotto una condizione della catena di boot utilizzabile da un exploit BootROM più vecchio.

Questa catena illustra perché la sicurezza di un dispositivo dipende da più della semplice patch di un singolo livello. Un'escalation di privilegi del kernel può diventare un ponte verso la persistenza di livello inferiore o il compromesso della catena di boot quando il software privilegiato può modificare lo stato del firmware critico per la sicurezza.

Struttura del repository

.
├── 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

Questo repository non ridistribuisce gli archivi ZIP di terze parti. Ottienili dalle guide XDA originali, rivedi i loro termini applicabili e confronta i loro hash con i valori registrati sopra.

Crediti

• NebuSec / CyberMeowfia — scoperta e ricerca originale IonStack/GhostLock e implementazione dell'exploit per CVE-2026-43499.
• R0rt1z2 — adattamento a Fire OS, il branch GhostLock 4.4 e la guida al root temporaneo e al downgrade per sheldon/sheldonp.
• IonStackQuest3 — primo port pubblico di GhostLock per kernel Linux 5.10, accreditato dal progetto Fire OS downstream.
• Collaboratori di Amonet/Kamakiri, inclusi xyz, k4y0z, Rortiz2, t0x1cSH e i tester accreditati nel thread originale di sblocco — lavoro su BootROM, fastboot, recovery e sblocco specifico per dispositivo.

Il mio contributo è la riproduzione indipendente, il resoconto di esecuzione specifico per il dispositivo, l'analisi di come le fasi si connettono e le prove originali pubblicate in questo repository.

Riferimenti

Il registro delle fonti mantenuto è in references/README.md. Le fonti primarie includono:

• Record CVE-2026-43499
• NebuSec: voce sulla vulnerabilità GhostLock
• NebuSec: IonStack Parte III — Sfruttamento Android
• CyberMeowfia: sorgente IonStack/CVE-2026-43499
• R0rt1z2/GhostLock, branch 4.4
• XDA: root temporaneo e downgrade del preloader per sheldon/sheldonp
• Sorgente Amonet/Kamakiri
• XDA: guida allo sblocco del bootloader, TWRP e unbrick per sheldon/sheldonp
• Fix del kernel Linux per remove_waiter()

Avviso sull'uso responsabile

Questo materiale è fornito per uso educativo e ricerca di sicurezza autorizzata su hardware di tua proprietà o che sei esplicitamente autorizzato a testare. Viene fornito senza alcuna garanzia. Sei responsabile della conformità legale, della perdita di dati, dell'interruzione del servizio e dei danni hardware derivanti dalle tue azioni.

Licenza

Il testo e le immagini originali creati per questo repository sono concessi in licenza sotto la Creative Commons Attribution 4.0 International License.

Strumenti di terze parti, codice di exploit, firmware, citazioni, screenshot, marchi e materiali referenziati rimangono soggetti alla rispettiva paternità e licenze. L'inclusione di un link o di un credito non relicenzia quel materiale sotto CC BY 4.0.