usbliter8: a falha de hardware que compromete o SecureROM da Apple em A12/A13 e não tem adesivo

Em 18 de junho de 2026 foi publicada uma pesquisa técnica e um teste de conceito que muda o panorama para vários dispositivos Apple: o exploit chamado usbliter8 Permite executar código arbitrário dentro do SecureROM de chips A12 e A13, o código que queima no silicone durante o fabrico e que nenhuma atualização de software pode modificar.

A raiz do problema é uma falha de hardware no driver USB Synopsys DWC2: a unidade DMA que guarda pacotes USB Setup pode retroceder seu ponteiro de escrita por um desfase entre como o índice é reiniciado e como são aceitos pacotes mais curtos do que o habitual, provocando um underflow replicável do buffer. Isso por si só não bastaria, mas em A12 e A13 Apple configurou o DART (o IOMMU do USB dentro de SecureROM) em um modo de bypass que permite que esses ponteiros DMA escritos para trás alcancem e corrompan SRAM arbitrária. Com cadeias de técnicas adicionais (incluindo uma evasão por etapas de Pointer Authentication em A13), os pesquisadores conseguem execução em nível privilegiado (EL1) dentro de SecureROM em menos de dois segundos desde que o dispositivo está em modo DFU e conectado por USB a um microcontrolador dedicado.

É importante entender o alcance prático. Isto não é um ataque remoto: requer a posse física do dispositivo, forçar o modo DFU e dispor do hardware adequado e do conhecimento para explorá-lo. As famílias afetadas incluem iPhone XS/XS Max/XR, iPhone 11/11 Pro, iPhone SE (2a gene), vários iPads com A12/A13, Apple Watch Series 4/5 e HomePod mini, entre outros; A11 não está afetado e A14 e gerações posteriores parecem imunes a esta via, segundo pesquisadores. A analogia técnica e operacional mais próxima na história recente é o exploit checkm8 de 2019, que deixou fora do alcance de adesivos para os chips A5–A11; para contexto técnico e prévio ver a página pública sobre checkm8 https://en.wikipedia.org/wiki/Checkm8.

As implicações para a segurança corporativa e de alto risco são claras e duras: não existe um adesivo de software que feche esta porta. Qualquer dispositivo com um SoC afetado mantém a vulnerabilidade enquanto houver fisicamente o silício. Para usuários individuais, a probabilidade de se encontrar com um atacante com as capacidades necessárias é baixa, mas para governos, empresas com dados sensíveis ou papéis com requisitos de custódia rigorosos é uma situação de custódia e remoção de hardware.

Recomendações práticas imediatas: primeiro, inventariar equipamentos que utilizem A12/A13/S4/S5 e classificá-los por criticidade; segundo, priorizar a substituição por equipamentos com A14 ou posteriores para papéis onde a integridade física e de arranque seja crítica; terceiro, aplicar controles físicos estritos: não deixar dispositivos negligenciados, usar armazenamento e cadeia de custódia com registro e selos, e evitar que os dispositivos sejam conectados via USB a hosts ou cabos não controlados. Cabe destacar que muitas contramedidas de software não aplicam: o exploit opera antes da cadeia de arranque assinada e não depende da configuração do sistema operacional, pelo que ferramentas como a gestão móvel empresarial ou as políticas de sistema não poderão impedir a exploração se o adversário tiver o dispositivo em mão.

Algumas medidas complementares e realistas para reduzir o risco: evitar deixar dispositivos em modo DFU ou fisicamente acessíveis, aplicar selos físicos e controles de entrada/saída em áreas de alta segurança, e considerar o uso de dispositivos de reserva ou hardware dedicado a funções sensíveis que já estejam em gerações mais novas. Para usuários que queiram verificar se seu dispositivo corresponde a um modelo potencialmente afetado, a Apple mantém documentação para identificar modelos e especificações que pode ser consultada na sua página de suporte sobre modelos de iPhone e iPad https://support.apple.com/en-us/HT201296.

Um ponto crítico: os pesquisadores não demonstraram acesso direto ao Secure Enclave, e a Apple concebeu esse componente como uma fronteira separada, mas a tomada de controle do BootROM e do SecureROM abre novos vetores que poderiam facilitar ataques físicos adicionais Consequentemente, não é conveniente analisar a ausência de uma prova de compromissos do enclave como garantia definitiva de segurança.

Finalmente, o fato de o teste de conceito e o código estarem públicos mudar a equação: o que hoje é pesquisa e demonstração pode tornar-se amanhã uma ferramenta mais acessível para atores com recursos. Os responsáveis pela segurança devem assumir que a disponibilidade pública reduz a barreira técnica e ajustar políticas de custódia, requisitos de hardware e ciclos de renovação em conformidade. Para manter-se informado sobre avisos oficiais e padrões de exploração, recomenda-se a monitorização dos comunicados do fabricante e das bases de dados e centros de resposta a incidentes; para referência geral sobre divulgação de vulnerabilidades e performances do CERT/NVD, ver NIST NVD https://nvd.nist.gov/.

Em suma, usbliter8 é um lembrete duro de que as vulnerabilidades de hardware podem ser permanentes e que a segurança física e a seleção de plataforma são decisões estratégicas: controlar quem tem acesso físico ao dispositivo e quando pode ser conectado por USB forma agora parte da superfície de segurança que as organizações devem gerir ativamente.