Pesquisadores da Paradigm Shift publicaram prova de conceito que executa código arbitrário no SecureROM via falha de hardware no controlador USB Synopsys DWC2, exigindo posse física do dispositivo em modo DFU
| Componente | SecureROM de SoCs Apple A12, A13, S4 e S5; controlador USB Synopsys DWC2 com DMA; configuração DART em bypass dentro do SecureROM |
| Vetor | Acesso físico ao dispositivo em modo DFU, conexão USB a placa microcontroladora baseada em RP2350; exploração de underflow repetível no ponteiro de escrita DMA durante pacotes Setup USB |
| Impacto | Execução arbitrária de código em EL1 dentro do SecureROM; possibilidade de carregar imagem iBoot não assinada, alterar modo de produção do SoC e marcar identificador USB com PWND:[usbliter8]; falha permanente no silício, fora do alcance de atualizações |
| Prioridade | Inventariar hardware A12/A13/S4/S5 em funções sensíveis, priorizar substituição por A14 ou posterior, reforçar custódia física e bloquear uso de cabos ou hosts USB não confiáveis em modo DFU |
| Versões | PoC público cobre A12, A13, S4 e S5; suporte teórico a A12X/A12Z não implementado; A11 mitigado por reset manual de endereço DMA; A14 e posteriores considerados inexploráveis neste caminho |
| Mitigação | Sem patch de firmware disponível; controle físico do dispositivo, política de descarte/substituição de equipamentos afetados e restrição de DFU em ambientes de alta segurança |
Pesquisadores do grupo Paradigm Shift divulgaram um exploit funcional denominado usbliter8 capaz de obter execução arbitrária de código dentro do SecureROM dos processadores Apple A12 e A13. O SecureROM é código gravado permanentemente no silício durante a fabricação e integra a primeira etapa da cadeia de confiança de boot da plataforma. Por residir abaixo de qualquer camada atualizável por software, a condição não pode ser removida por patch de sistema operacional ou firmware posterior ao uso contínuo do equipamento afetado.
A divulgação ocorreu em 18 de junho de 2026, após divulgação coordenada com a equipe Apple Product Security, incluindo write-up técnico completo e prova de conceito operacional. Até 19 de junho de 2026, não havia registro público de identificador CVE, pontuação CVSS, advisory oficial da Apple, alerta da CISA ou exploração confirmada em ambiente real. O cenário de risco permanece condicionado a acesso físico, conhecimento técnico e hardware auxiliar dedicado, mas o código público reduz a barreira para reutilização por terceiros em contextos de custódia comprometida ou exame forense abusivo.
A raiz do problema está em uma falha de hardware no controlador USB Synopsys DWC2. O periférico armazena pacotes Setup recebidos via DMA, mantém buffer para até três pacotes e, ao receber o quarto, reinicia o ponteiro de escrita decrementando-o em 24 bytes fixos. Simultaneamente, aceita pacotes menores que o tamanho padrão e avança o ponteiro apenas pelos bytes efetivamente escritos. Essa divergência entre decremento fixo e incremento variável acumula um underflow repetível no buffer, recuando o ponteiro de escrita 12 bytes por iteração até alcançar regiões de memória adjacentes.
No A12 e A13, a exploração torna-se viável porque a configuração do DART — Device Address Resolution Table, equivalente ao IOMMU do chip — dentro do SecureROM opera em modo bypass. Com isso, o ponteiro DMA comprometido pode alcançar e sobrescrever SRAM arbitrária. No A11, o driver USB reinicializa manualmente o endereço DMA após cada pacote, impedindo acúmulo do desalinhamento. Nos chips A14 e subsequentes, a Paradigm Shift indica configuração adequada do DART, o que bloqueia este caminho de exploração.
A execução exige posse física do aparelho colocado em modo DFU e conexão USB a uma placa microcontroladora baseada em RP2350. O processo completa em menos de dois segundos, antes do carregamento da cadeia de boot assinada pela Apple. No A12, o buffer DMA situa-se adjacente à pilha da tarefa USB no heap; sobrescrever um registrador de link salvo concede controle do contador de programa na próxima troca de contexto. No A13, a Autenticação de Ponteiro protege endereços de retorno na pilha, exigindo estágios adicionais: corrupção de estruturas relacionadas ao DART para obter primitivas limitadas de escrita, alteração do contador de profundidade de pânico para evitar reinicialização imediata e sincronização cuidadosa das escritas DMA para não destruir registradores salvos da tarefa USB. A etapa final substitui o ponteiro do manipulador de interrupção USB em BSS, fazendo com que a próxima interrupção USB execute código controlado pelo atacante. Ambos os caminhos terminam em execução no nível de privilégio EL1 dentro do SecureROM.
Após a exploração, usbliter8 injeta um manipulador personalizado de requisições USB e grava a marca PWND:[usbliter8] na string serial exposta via USB. A partir desse ponto, é possível rebaixar temporariamente o modo de produção do SoC ou iniciar uma imagem iBoot bruta sem verificação de assinatura, saindo integralmente da cadeia de confiança da Apple. A pesquisa não demonstra comprometimento do Secure Enclave, que permanece projetado como domínio isolado do processador de aplicação, embora o controle no nível BootROM possa abrir rotas ainda não detalhadas publicamente para ataques subsequentes. O precedente mais próximo é o exploit checkm8, de 2019, que colocou permanentemente dispositivos A5 até A11 fora da autoridade de correção da Apple; usbliter8 estende essa condição à geração imediatamente seguinte de silício.
A prova de conceito pública cobre os SoCs A12, A13, S4 e S5. Suporte a A12X e A12Z é descrito como teoricamente possível, porém ainda não implementado na ferramenta divulgada. O A11 não entra no escopo desta falha específica. Dispositivos A14 e posteriores aparecem fora do alcance deste vetor conforme a análise publicada.
Entre as familias citadas na pesquisa estão iPhone XS, XS Max e XR; iPhone 11, 11 Pro e 11 Pro Max; iPhone SE de segunda geração; iPad Air de terceira geração, iPad mini de quinta geração e iPad de oitava geração; Apple Watch Series 4 e 5; Apple Watch SE de primeira geração; HomePod mini; e demais produtos construídos sobre os chips listados. Qualquer ambiente que trate esses equipamentos como barreira confiável contra modificação de boot ou extração offline de dados deve revisar essa premissa.
- SoCs diretamente cobertos pelo PoC: A12, A13, S4 e S5
- Chips fora do escopo imediato: A11 mitigado; A14+ considerados inexploráveis neste caminho
- Pré-condição operacional: posse física, modo DFU e host USB controlado via placa RP2350
- Impacto persistente: falha permanente no hardware, independente de ciclo de patches de software
Como o ataque ocorre antes do boot assinado e depende de interface USB em DFU, a detecção em endpoints corporativos convencionais é limitada. A telemetria útil concentra-se em controles físicos, inventário de ativos e sinais pós-exploração visíveis apenas durante a sessão USB ativa.
Equipes de segurança devem correlacionar inventário de hardware com geração de chip, registrar incidentes de dispositivos desaparecidos ou submetidos a exame externo e monitorar políticas de uso de cabos ou estáções de carga compartilhadas em áreas sensíveis. Em laboratórios forenses ou salas de custódia, qualquer aparelho retornado após período em que não houve supervisão direta merece tratamento como potencialmente alterado no boot chain.
- String serial USB contendo a marca PWND:[usbliter8] durante conexão ativa pós-exploração
- Tentativas de boot com imagem iBoot não assinada ou alteração temporária de modo de produção do SoC
- Sessões DFU iniciadas em dispositivos A12/A13/S4/S5 fora de fluxos autorizados de manutenção ou recuperação
- Presença de hardware auxiliar RP2350 ou hosts USB desconhecidos conectados a equipamentos sensíveis
Não existe correção de firmware que alcance o SecureROM nestes chips; a mitigação é estrutural e operacional. Para a maioria dos usuários finais, o risco prático permanece baixo porque exige posse do aparelho, cabo adequado e capacidade de forçar o modo DFU. Em ambientes de alta segurança, porém, a fronteira física deixa de ser garantia absoluta e passa a depender de custódia rigorosa e substituição de hardware.
Organizações devem tratar dispositivos com A12, A13, S4 ou S5 em funções críticas — custódia de segredos, autenticação forte, comunicações sensíveis ou isolamento de dados — como candidatos prioritários a refresh para A14 ou gerações mais recentes. Políticas de mesa limpa, armazenamento seguro, proibição de DFU em cabos ou hosts não confiáveis e descarte controlado de unidades retiradas de circulação reduzem a janela de abuso físico. Como o código da exploração foi publicado, a pesquisa deixa de ser apenas demonstração acadêmica e passa a integrar o repertório disponível para reutilização por terceiros com acesso físico ao equipamento.
- Mapear e rotular todo inventário baseado em A12, A13, S4 ou S5 em papéis sensíveis
- Priorizar substituição por hardware A14 ou posterior onde a integridade de boot é requisito de compliance
- Proibir ou restringir modo DFU fora de bancadas forenses autorizadas e supervisionadas
- Retirar de serviço unidades comprometidas ou submetidas a custódia duvidosa; não confiar em reinstalação de software como remediação completa
0 Comentários