CVE-2026-43499 no Amazon Fire TV Stick 3ª Geração (sheldonp)

Encadeando uma escalada de privilégios no kernel Linux em um downgrade de preloader e desbloqueio de bootloader.

Visão geral

Este repositório documenta minha reprodução autorizada da cadeia de exploração CVE-2026-43499 em um Amazon Fire TV Stick 3ª Geração (sheldonp). A cadeia utilizou root temporário no kernel para executar um downgrade controlado de preloader e, em seguida, usou o fluxo de trabalho existente do Kamakiri BootROM para alcançar o fastboot desbloqueado e concluir o desbloqueio do bootloader.

Esta é uma reprodução e um estudo de caso específico do dispositivo. Não descobri o CVE-2026-43499, não criei o exploit original IonStack/GhostLock, nem desenvolvi o Kamakiri. Os pesquisadores e desenvolvedores originais são creditados abaixo.

[!IMPORTANT] Este artigo é um registro técnico, não um guia universal de root. A compatibilidade de build importa, root temporário não é root persistente, e erros envolvendo Preloader, LK, TEE ou partições protegidas por dm-verity podem brickar o dispositivo permanentemente.

Registro de reprodução

A cadeia completa foi concluída em 12 de setembro de 2026. Este repositório registra o dispositivo testado e as versões de software, os arquivos exatos utilizados, seus hashes SHA-256 e as evidências originais capturadas durante o processo.

Escopo

Fora do escopo: descoberta de vulnerabilidade, uma nova implementação de exploit, exploração remota, root persistente ou suporte para dispositivos diferentes da unidade sheldonp testada. Nenhuma ROM customizada foi instalada durante esta reprodução.

Arquivos de reprodução

Os seguintes são os arquivos ZIP exatos utilizados durante esta reprodução. Os arquivos não são redistribuídos neste repositório; seus hashes SHA-256 são registrados para que cópias obtidas independentemente possam ser comparadas com os arquivos usados neste estudo de caso.

Esses hashes identificam as cópias usadas neste estudo de caso; os leitores ainda devem comparar seus downloads com as fontes originais upstream e revisar as licenças de terceiros aplicáveis.

Contexto técnico

CVE-2026-43499, também conhecido como GhostLock, é um use-after-free no caminho futex/rtmutex de herança de prioridade do kernel Linux. Durante o rollback do proxy-lock, remove_waiter() operava sobre current em vez da tarefa armazenada em waiter->task. Como resultado, o waiter real poderia retornar ao espaço do usuário com pi_blocked_on ainda referenciando um rt_mutex_waiter em um frame de pilha do kernel já liberado.

A pesquisa original do IonStack transforma essa referência de pilha pendente em uma primitiva de escalada de privilégios local. R0rt1z2 adaptou a técnica para o Fire TV Stick 3ª Geração e o Fire TV Stick Lite (sheldonp/sheldon) executando Fire OS 7 em um kernel 4.4.

A distinção fundamental neste estudo de caso é que o CVE-2026-43499 não desbloqueia o bootloader diretamente. Ele fornece acesso temporário em nível de kernel. Esse acesso de curta duração torna possível realizar o downgrade controlado de preloader necessário antes que a cadeia mais antiga do Kamakiri BootROM possa ser executada.

Cadeia de exploração

flowchart LR
    A[Fire OS 7 no sheldonp] --> B[CVE-2026-43499 / GhostLock]
    B --> C[Shell root temporário]
    C --> D[Downgrade controlado de preloader]
    D --> E[Estado de transição esperado sem boot]
    E --> F[Estágio Kamakiri BootROM]
    F --> G[Fastboot desbloqueado]
    G --> H[Bootloader desbloqueado]

A cadeia atravessa duas fronteiras de segurança distintas:

1. Fronteira do kernel: um processo local sem privilégios obtém um contexto root temporário através do GhostLock.
2. Fronteira da cadeia de boot: o root temporário prepara o dispositivo para um caminho de desbloqueio conhecido baseado em BootROM, restaurando um preloader compatível.

Metodologia

1. Estabelecer a linha de base

Antes de alterar o dispositivo, identifiquei o codinome do hardware e registrei as versões do Fire OS, build, bootloader e kernel 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

A linha de base resultante foi sheldonp / AFTSSS, Fire OS PS7716.5666N, incremental 0036005356164, Android 9 e kernel 4.4.162+. O número de série foi deliberadamente omitido.

2. Obter root temporário com o GhostLock

Conectei o Fire TV via USB com a depuração ADB habilitada e usei o GhostLock 1.1.0, o pacote sheldon/sheldonp publicado com o guia XDA do R0rt1z2. O launcher específico do dispositivo reinicia o Fire TV para começar de um estado limpo, implanta o exploit e tenta novamente quando necessário.

A exploração bem-sucedida cria um ambiente root temporário. Verifiquei o contexto de segurança a partir de um shell ADB em vez de tratar a conclusão do script como prova suficiente:

adb shell
su
id

O contexto root é efêmero e é perdido ao reiniciar. Esse comportamento é importante: este estágio é uma primitiva habilitadora para o downgrade, não o mecanismo de persistência final nem o desbloqueio do bootloader em si.

A execução bem-sucedida mostrou uid=0, alterou o SELinux para permissivo para o ambiente temporário, montou o su temporário e desabilitou os pacotes OTA do Fire OS tratados pela ferramenta.

O traço completo do exploit GhostLock é mantido como evidência de suporte.

3. Fazer downgrade do preloader

Com o root temporário disponível, usei o fluxo de trabalho dedicado de downgrade do pacote em vez de gravar manualmente as partições de firmware. Isso restaurou um preloader compatível com o caminho Kamakiri existente.

Após o downgrade, o Fire TV intencionalmente parou de inicializar no Fire OS. Neste fluxo de trabalho específico, esse estado sem boot é a transição esperada entre o estágio de kernel ativo e o estágio USB BootROM. Ele não deve ser confundido com prova de que uma gravação falha arbitrária é recuperável.

[!CAUTION] Nunca apague o Preloader. Não improvise gravações em LK, TEE, Preloader, boot, recovery, system, vendor ou outras partições protegidas. Os guias upstream alertam que danos ao firmware crítico podem causar um hard brick permanente, pois um caminho de recuperação funcional pode não permanecer disponível.

4. Executar a cadeia Kamakiri BootROM

O fluxo de trabalho Kamakiri usado para este dispositivo era suportado e documentado para Linux. Portanto, inicializei uma sessão Ubuntu Live e realizei todo o fluxo de desbloqueio ali, incluindo o estágio USB BootROM de baixo nível, sem instalar o Ubuntu no host. Não testei este estágio no Windows ou macOS.

Usando o pacote Kamakiri sheldon/sheldonp referenciado pelo guia de desbloqueio, o processo foi:

1. Preparar Python, PySerial, PyUSB, ADB, Fastboot e o ambiente USB exigido pelo Kamakiri.
2. Iniciar bootrom-step.sh e conectar o Fire TV desligado via USB.
3. Permitir que o estágio BootROM fosse concluído e fizesse a transição do dispositivo para o ambiente fastboot modificado.
4. Executar fastboot-step.sh para finalizar o fluxo de desbloqueio.
5. Reiniciar e verificar se o caminho de boot desbloqueado esperado estava disponível.

O Kamakiri detectou a unidade como sheldonp, concluiu o downgrade do RPMB, gravou os componentes TZ/LK exigidos pela cadeia, injetou o microloader e forçou o dispositivo ao seu modo fastboot modificado.

Os hashes dos arquivos e a versão do Ubuntu estão registrados acima. Os leitores devem usar os guias upstream vinculados para instruções específicas de versão, em vez de assumir que esses passos de alto nível se aplicam a outra build.

5. Validar o resultado

Tratei os seguintes como marcos separados e capturei evidências para cada um deles:

6. Preservar o Fire OS e ajustar o estado pós-desbloqueio

Meu objetivo era manter o Fire OS de fábrica em vez de instalar imediatamente uma ROM customizada. No TWRP, evitei apagar dados ou substituir o sistema operacional, e então reiniciei na instalação existente do Fire OS. O TWRP e o caminho de boot desbloqueado permaneceram disponíveis enquanto o ambiente de usuário de fábrica foi preservado.

Após retornar ao Fire OS, mantive as atualizações OTA desabilitadas para que a Amazon não pudesse mover silenciosamente o dispositivo para uma build que alterasse o exploit ou modificasse a cadeia de boot recuperada. Também desabilitei o componente de proteção de aplicativos do sistema da Amazon comumente referido nas ferramentas da comunidade Fire TV como ARCUS. Isso altera o comportamento de bloqueio de aplicativos em nível de SO da Amazon; não contorna o Widevine, verificações de assinatura ou aplicação de licenças implementadas dentro de aplicativos individuais.

Próximos passos opcionais

Um bootloader desbloqueado e o TWRP também tornam possível instalar software customizado compatível. Uma opção da comunidade para esta família de dispositivos é o LineageOS 20 baseado no Android 13. Outras ROMs compatíveis, fluxos de trabalho de recuperação ou configurações de root persistente também podem ser possíveis.

Essas alternativas não fizeram parte desta reprodução. Elas devem ser tratadas como procedimentos separados com suas próprias considerações de firmware, TZ, apagamento de dados, DRM, memória e recuperação.

Observações

• Uma conexão ADB USB com fio é preferível, pois as tentativas do exploit podem reiniciar o alvo e interromper o ADB sem fio.
• A confiabilidade do exploit depende do alvo e da build. Uma nova tentativa ou reinicialização não é evidência de que um dispositivo não é suportado, mas os offsets e a compatibilidade de build ainda devem ser verificados.
• O estágio de root temporário e o estágio Kamakiri resolvem problemas diferentes e devem ser documentados independentemente.
• O estado esperado sem boot após o downgrade só é significativo quando a ferramenta de downgrade relata sucesso e o fluxo de trabalho suportado exato está sendo seguido.
• Uma saída de script bem-sucedida é evidência mais fraca do que o estado capturado do dispositivo, a identidade root e a verificação de fastboot/recovery.
• Desbloquear o bootloader não exigiu substituir o Fire OS; manter o Fire OS de fábrica foi uma escolha deliberada pós-desbloqueio.
• Desabilitar o ARCUS afeta a camada de bloqueio de aplicativos da Amazon, enquanto o DRM de aplicativos e as licenças de conteúdo permanecem questões separadas.

Impacto de segurança

Em uma build do Fire OS vulnerável e suportada, código já em execução local no dispositivo pode explorar a falha do kernel para obter um contexto root temporário. Neste laboratório, esse acesso expandiu a superfície de ataque além do sistema operacional em execução: permitiu um downgrade de firmware que reintroduziu uma condição da cadeia de boot utilizável por um exploit de BootROM mais antigo.

Essa cadeia ilustra por que a segurança do dispositivo depende de mais do que corrigir uma única camada. Uma escalada de privilégios no kernel pode se tornar uma ponte para persistência de nível inferior ou comprometimento da cadeia de boot quando software privilegiado pode modificar o estado de firmware crítico para a segurança.

Estrutura do repositório

.
├── README.md              # Estudo de caso e metodologia
├── LICENSE                # CC BY 4.0 para documentação e mídia originais
├── images/
│   ├── README.md          # Índice de evidências e orientação de redação
│   └── evidence/          # Capturas de tela e fotografias sanitizadas
└── references/
    └── README.md          # Registro de fontes e orientação de artefatos

Este repositório não redistribui os arquivos ZIP de terceiros. Obtenha-os nos guias originais do XDA, revise seus termos aplicáveis e compare seus hashes com os valores registrados acima.

Créditos

• NebuSec / CyberMeowfia — descoberta e pesquisa original do IonStack/GhostLock e implementação do exploit para CVE-2026-43499.
• R0rt1z2 — adaptação para Fire OS, o branch 4.4 do GhostLock e o guia de root temporário e downgrade para sheldon/sheldonp.
• IonStackQuest3 — primeiro port público do GhostLock para kernels Linux 5.10, creditado pelo projeto downstream do Fire OS.
• Colaboradores do Amonet/Kamakiri, incluindo xyz, k4y0z, Rortiz2, t0x1cSH e testadores creditados no tópico original de desbloqueio — trabalho de BootROM, fastboot, recuperação e desbloqueio específico do dispositivo.

Minha contribuição é a reprodução independente, o registro de execução específico do dispositivo, a análise de como os estágios se conectam e as evidências originais publicadas neste repositório.

Referências

O registro de fontes mantido está em references/README.md. As fontes primárias incluem:

• Registro do CVE-2026-43499
• NebuSec: entrada da vulnerabilidade GhostLock
• NebuSec: IonStack Parte III — exploração no Android
• CyberMeowfia: código-fonte do IonStack/CVE-2026-43499
• R0rt1z2/GhostLock, branch 4.4
• XDA: root temporário e downgrade de preloader para sheldon/sheldonp
• Código-fonte do Amonet/Kamakiri
• XDA: guia de desbloqueio de bootloader, TWRP e unbrick para sheldon/sheldonp
• Correção do kernel Linux para remove_waiter()

Aviso de uso responsável

Este material é fornecido para uso educacional e pesquisa de segurança autorizada em hardware que você possui ou tem permissão explícita para testar. Ele não vem com nenhuma garantia. Você é responsável pela conformidade legal, perda de dados, interrupção de serviço e danos ao hardware resultantes de suas ações.

Licença

O texto e as imagens originais criados para este repositório estão licenciados sob a Creative Commons Attribution 4.0 International License.

Ferramentas de terceiros, código de exploit, firmware, citações, capturas de tela, marcas registradas e materiais referenciados permanecem sujeitos à sua respectiva autoria e licenças. A inclusão de um link ou crédito não relicencia esse material sob CC BY 4.0.