CVE-2026-43499 auf Amazon Fire TV Stick 3. Gen (sheldonp)

Verkettung einer Linux-Kernel-Privilegieneskalation mit einem Preloader-Downgrade und Bootloader-Unlock.

Überblick

Dieses Repository dokumentiert meine autorisierte Reproduktion der Exploit-Kette CVE-2026-43499 auf einem Amazon Fire TV Stick 3. Gen (sheldonp). Die Kette nutzte temporären Kernel-Root, um ein kontrolliertes Preloader-Downgrade durchzuführen, und verwendete anschließend den bestehenden Kamakiri-BootROM-Workflow, um einen entsperrten Fastboot zu erreichen und den Bootloader-Unlock abzuschließen.

Dies ist eine Reproduktion und eine gerätespezifische Fallstudie. Ich habe CVE-2026-43499 nicht entdeckt, den ursprünglichen IonStack/GhostLock-Exploit nicht erstellt und Kamakiri nicht entwickelt. Die Upstream-Forscher und -Entwickler werden unten genannt.

[!IMPORTANT] Dieser Write-up ist eine technische Aufzeichnung, keine universelle Rooting-Anleitung. Build-Kompatibilität ist wichtig, temporärer Root ist kein persistenter Root, und Fehler im Umgang mit Preloader, LK, TEE oder dm-verity-geschützten Partitionen können das Gerät dauerhaft bricken.

Reproduktionsprotokoll

Die Ende-zu-Ende-Kette wurde am 12. September 2026 abgeschlossen. Dieses Repository dokumentiert das getestete Gerät und die Softwareversionen, die exakt verwendeten Archive, deren SHA-256-Hashes und die während des Prozesses erfassten Originalbelege.

Umfang

Nicht im Umfang enthalten: Schwachstellensuche, eine neue Exploit-Implementierung, Remote-Exploitation, persistenter Root oder Unterstützung für andere Geräte als das getestete sheldonp-Exemplar. Während dieser Reproduktion wurde kein Custom-ROM installiert.

Reproduktionsarchive

Die folgenden ZIP-Archive wurden während dieser Reproduktion exakt verwendet. Die Archive werden in diesem Repository nicht weiterverbreitet; ihre SHA-256-Hashes sind aufgezeichnet, damit unabhängig beschaffte Kopien mit den in dieser Fallstudie verwendeten Dateien verglichen werden können.

Diese Hashes identifizieren die in dieser Fallstudie verwendeten Kopien; Leser sollten ihre Downloads dennoch mit den ursprünglichen Upstream-Quellen vergleichen und die geltenden Lizenzen Dritter prüfen.

Technischer Hintergrund

CVE-2026-43499, auch bekannt als GhostLock, ist eine Use-after-Free-Schwachstelle im Priority-Inheritance-Futex/rtmutex-Pfad des Linux-Kernels. Während des Proxy-Lock-Rollbacks arbeitete remove_waiter() auf current statt auf der in waiter->task gespeicherten Task. Infolgedessen konnte der tatsächliche Waiter in den Userspace zurückkehren, während pi_blocked_on noch auf einen rt_mutex_waiter in einem freigegebenen Kernel-Stackframe verwies.

Die ursprüngliche IonStack-Forschung verwandelt diese baumelnde Stack-Referenz in ein lokales Privilegieneskalations-Primitiv. R0rt1z2 passte die Technik an den Fire TV Stick 3. Gen und den Fire TV Stick Lite (sheldonp/sheldon) mit Fire OS 7 auf einem 4.4-Kernel an.

Der entscheidende Unterschied in dieser Fallstudie besteht darin, dass CVE-2026-43499 den Bootloader nicht direkt entsperrt. Es bietet temporären Zugriff auf Kernel-Ebene. Dieser kurzlebige Zugriff ermöglicht das kontrollierte Preloader-Downgrade, das erforderlich ist, bevor die ältere Kamakiri-BootROM-Kette ausgeführt werden kann.

Exploit-Kette

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]

Die Kette überschreitet zwei separate Sicherheitsgrenzen:

1. Kernel-Grenze: Ein unprivilegierter lokaler Prozess erlangt über GhostLock einen temporären Root-Kontext.
2. Boot-Chain-Grenze: Temporärer Root bereitet das Gerät auf einen bekannten BootROM-basierten Unlock-Pfad vor, indem ein kompatibler Preloader wiederhergestellt wird.

Methodik

1. Baseline herstellen

Bevor ich das Gerät veränderte, identifizierte ich den Hardware-Codename und zeichnete die Fire OS-, Build-, Bootloader- und Kernel-Versionen über ADB auf.

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

Die resultierende Baseline war sheldonp / AFTSSS, Fire OS PS7716.5666N, Incremental 0036005356164, Android 9 und Kernel 4.4.162+. Die Seriennummer wird bewusst weggelassen.

2. Temporären Root mit GhostLock erlangen

Ich verband den Fire TV über USB mit aktiviertem ADB-Debugging und verwendete GhostLock 1.1.0, das sheldon/sheldonp-Paket, das mit der R0rt1z2-XDA-Anleitung veröffentlicht wurde. Der gerätespezifische Launcher startet den Fire TV neu, um von einem frischen Zustand aus zu beginnen, setzt den Exploit ab und wiederholt den Vorgang bei Bedarf.

Eine erfolgreiche Ausnutzung erzeugt eine temporäre Root-Umgebung. Ich verifizierte den Sicherheitskontext aus einer ADB-Shell, statt allein den Abschluss des Skripts als Beweis zu betrachten:

adb shell
su
id

Der Root-Kontext ist flüchtig und geht beim Neustart verloren. Dieses Verhalten ist wichtig: Diese Phase ist ein ermöglichendes Primitiv für das Downgrade, nicht der endgültige Persistenzmechanismus oder der Bootloader-Unlock selbst.

Der erfolgreiche Durchlauf zeigte uid=0, änderte SELinux für die temporäre Umgebung auf permissive, mountete das temporäre su und deaktivierte die vom Tool behandelten Fire OS-OTA-Pakete.

Der vollständige GhostLock-Exploit-Trace ist als unterstützender Beleg erhalten.

3. Den Preloader downgraden

Mit verfügbarem temporärem Root verwendete ich den dedizierten Downgrade-Workflow des Pakets, statt Firmware-Partitionen manuell zu beschreiben. Dadurch wurde ein Preloader wiederhergestellt, der mit dem bestehenden Kamakiri-Pfad kompatibel ist.

Nach dem Downgrade startete der Fire TV absichtlich nicht mehr in Fire OS. In diesem spezifischen Workflow ist dieser nicht bootende Zustand die erwartete Übergabe zwischen der Live-Kernel-Phase und der USB-BootROM-Phase. Er darf nicht mit dem Beweis verwechselt werden, dass ein beliebig fehlgeschlagener Flash wiederherstellbar ist.

[!CAUTION] Den Preloader niemals löschen. Keine improvisierten Schreibvorgänge auf LK, TEE, Preloader, boot, recovery, system, vendor oder andere geschützte Partitionen durchführen. Die Upstream-Anleitungen warnen, dass Schäden an kritischer Firmware zu einem permanenten Hard-Brick führen können, weil möglicherweise kein funktionierender Wiederherstellungspfad mehr verfügbar ist.

4. Die Kamakiri-BootROM-Kette ausführen

Der für dieses Gerät verwendete Kamakiri-Workflow wurde für Linux unterstützt und dokumentiert. Daher bootete ich eine Ubuntu-Live-Sitzung und führte den vollständigen Unlock-Workflow dort durch, einschließlich der Low-Level-USB-BootROM-Phase, ohne Ubuntu auf dem Host zu installieren. Ich habe diese Phase nicht unter Windows oder macOS getestet.

Unter Verwendung des sheldon/sheldonp-Kamakiri-Pakets, auf das die Unlock-Anleitung verweist, verlief der Prozess wie folgt:

1. Python, PySerial, PyUSB, ADB, Fastboot und die von Kamakiri benötigte USB-Umgebung vorbereiten.
2. bootrom-step.sh starten und den ausgeschalteten Fire TV über USB verbinden.
3. Die BootROM-Phase abschließen lassen und das Gerät in die modifizierte Fastboot-Umgebung überführen.
4. fastboot-step.sh ausführen, um den Unlock-Workflow abzuschließen.
5. Neu starten und verifizieren, dass der erwartete entsperrte Boot-Pfad verfügbar war.

Kamakiri erkannte das Exemplar als sheldonp, schloss das RPMB-Downgrade ab, flashte die von der Kette benötigten TZ/LK-Komponenten, injizierte den Microloader und zwang das Gerät in seinen gehackten Fastboot-Modus.

Die Archiv-Hashes und die Ubuntu-Version sind oben aufgezeichnet. Leser sollten die verlinkten Upstream-Anleitungen für versionsspezifische Anweisungen verwenden, statt anzunehmen, dass diese übergeordneten Schritte auf einen anderen Build anwendbar sind.

5. Das Ergebnis validieren

Ich behandelte die folgenden Punkte als separate Meilensteine und erfasste für jeden einen Beleg:

6. Fire OS erhalten und den Zustand nach dem Unlock anpassen

Mein Ziel war es, das Stock-Fire-OS zu erhalten, statt sofort ein Custom-ROM zu installieren. In TWRP vermied ich das Löschen von Daten oder das Ersetzen des Betriebssystems und startete dann in die bestehende Fire OS-Installation neu. TWRP und der entsperrte Boot-Pfad blieben verfügbar, während die Stock-Benutzerumgebung erhalten blieb.

Nach der Rückkehr zu Fire OS hielt ich OTA-Updates deaktiviert, damit Amazon das Gerät nicht stillschweigend auf einen Build verschieben konnte, der den Exploit veränderte oder die wiederhergestellte Boot-Kette modifizierte. Außerdem deaktivierte ich die Amazon-System-App-Schutzkomponente, die in der Fire TV-Community-Tooling üblicherweise als ARCUS bezeichnet wird. Dies ändert Amazons App-Blockierungsverhalten auf OS-Ebene; es umgeht nicht Widevine, Abonnementprüfungen oder Lizenzdurchsetzung, die innerhalb einzelner Anwendungen implementiert sind.

Optionale nächste Schritte

Ein entsperrter Bootloader und TWRP ermöglichen auch die Installation kompatibler Custom-Software. Eine Community-Option für diese Gerätefamilie ist LineageOS 20 auf Basis von Android 13. Andere kompatible ROMs, Recovery-Workflows oder persistente Root-Konfigurationen sind ebenfalls möglich.

Diese Alternativen waren nicht Teil dieser Reproduktion. Sie sollten als separate Verfahren mit eigenen Überlegungen zu Firmware, TZ, Datenlöschung, DRM, Speicher und Wiederherstellung behandelt werden.

Beobachtungen

• Eine kabelgebundene USB-ADB-Verbindung ist vorzuziehen, da Exploit-Wiederholungen das Ziel neu starten und drahtloses ADB unterbrechen können.
• Die Zuverlässigkeit des Exploits ist ziel- und buildabhängig. Ein Wiederholungsversuch oder Neustart ist kein Beweis dafür, dass ein Gerät nicht unterstützt wird, aber Offsets und Build-Kompatibilität müssen dennoch verifiziert werden.
• Die Phase des temporären Roots und die Kamakiri-Phase lösen unterschiedliche Probleme und sollten unabhängig dokumentiert werden.
• Der erwartete nicht bootende Zustand nach dem Downgrade ist nur dann aussagekräftig, wenn das Downgrade-Tool Erfolg meldet und der exakt unterstützte Workflow befolgt wird.
• Ein erfolgreicher Skript-Abschluss ist ein schwächerer Beleg als der erfasste Gerätezustand, die Root-Identität und die Fastboot-/Recovery-Verifikation.
• Das Entsperren des Bootloaders erforderte nicht das Ersetzen von Fire OS; das Beibehalten des Stock-Fire-OS war eine bewusste Entscheidung nach dem Unlock.
• Das Deaktivieren von ARCUS betrifft Amazons App-Blockierungsschicht, während Anwendungs-DRM und Inhaltslizenzen separate Angelegenheiten bleiben.

Sicherheitsauswirkung

Auf einem verwundbaren und unterstützten Fire OS-Build kann Code, der bereits lokal auf dem Gerät läuft, die Kernel-Schwachstelle ausnutzen, um einen temporären Root-Kontext zu erlangen. In diesem Lab erweiterte dieser Zugriff die Angriffsfläche über das laufende Betriebssystem hinaus: Er ermöglichte ein Firmware-Downgrade, das eine Boot-Chain-Bedingung wieder einführte, die von einem älteren BootROM-Exploit genutzt werden konnte.

Diese Kette veranschaulicht, warum Gerätesicherheit von mehr als dem Patchen einer einzelnen Schicht abhängt. Eine Kernel-Privilegieneskalation kann zu einer Brücke zu Persistenz auf niedrigerer Ebene oder zur Kompromittierung der Boot-Kette werden, wenn privilegierte Software sicherheitskritischen Firmware-Zustand verändern kann.

Repository-Struktur

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

Dieses Repository verbreitet die ZIP-Archive Dritter nicht weiter. Beschaffen Sie sie aus den ursprünglichen XDA-Anleitungen, prüfen Sie deren geltende Bedingungen und vergleichen Sie ihre Hashes mit den oben aufgezeichneten Werten.

Danksagungen

• NebuSec / CyberMeowfia — Entdeckung und ursprüngliche IonStack/GhostLock-Forschung und Exploit-Implementierung für CVE-2026-43499.
• R0rt1z2 — Fire OS-Anpassung, der 4.4-GhostLock-Branch und die Anleitung zu temporärem Root und Downgrade für sheldon/sheldonp.
• IonStackQuest3 — erster öffentlicher GhostLock-Port für Linux-5.10-Kernel, gewürdigt vom nachgelagerten Fire OS-Projekt.
• Amonet/Kamakiri-Mitwirkende, einschließlich xyz, k4y0z, Rortiz2, t0x1cSH und der im ursprünglichen Unlock-Thread genannten Tester — BootROM-, Fastboot-, Recovery- und gerätespezifische Unlock-Arbeit.

Mein Beitrag ist die unabhängige Reproduktion, die gerätespezifische Ausführungsaufzeichnung, die Analyse, wie die Phasen zusammenhängen, und die in diesem Repository veröffentlichten Originalbelege.

Referenzen

Das gepflegte Quellenverzeichnis befindet sich in references/README.md. Primärquellen umfassen:

• CVE-2026-43499-Eintrag
• NebuSec: GhostLock-Schwachstelleneintrag
• NebuSec: IonStack Teil III — Android-Exploitation
• CyberMeowfia: IonStack/CVE-2026-43499-Quellcode
• R0rt1z2/GhostLock, Branch 4.4
• XDA: temporärer Root und Preloader-Downgrade für sheldon/sheldonp
• Amonet/Kamakiri-Quellcode
• XDA: Anleitung zu Bootloader-Unlock, TWRP und Unbrick für sheldon/sheldonp
• Linux-Kernel-Fix für remove_waiter()

Hinweis zur verantwortungsvollen Nutzung

Dieses Material wird für Bildungszwecke und autorisierte Sicherheitsforschung an Hardware bereitgestellt, die Sie besitzen oder für deren Test Sie ausdrücklich berechtigt sind. Es wird ohne Gewähr bereitgestellt. Sie sind verantwortlich für die rechtliche Einhaltung, Datenverlust, Dienstunterbrechungen und Hardwareschäden, die aus Ihren Handlungen resultieren.

Lizenz

Der für dieses Repository verfasste Originaltext und die Bilder sind unter der Creative Commons Attribution 4.0 International License lizenziert.

Tools, Exploit-Code, Firmware, Zitate, Screenshots, Marken und referenziertes Material Dritter unterliegen weiterhin ihrer jeweiligen Urheberschaft und ihren jeweiligen Lizenzen. Die Aufnahme eines Links oder einer Nennung stellt keine Relizenzierung dieses Materials unter CC BY 4.0 dar.