Pesquisa técnica descreve como trustlets Qualcomm podem ser emulados, instrumentados e testados por cobertura, incluindo uma falha reproduzível no trustlet prov em Nexus 6 e Moto G4.
| Componente | Aplicativos confiáveis Qualcomm QSEE, incluindo o trustlet prov, executados no ambiente ARM TrustZone. |
| Vetor | Buffers de requisição enviados do Mundo Normal para o manipulador de comandos do trustlet, com comandos externos processados dentro do Mundo Seguro. |
| Impacto | Crash reproduzível no trustlet prov quando o manipulador do comando 0x7000D recebe primeiro argumento maior que 9999; vulnerabilidades em TEE podem afetar dados protegidos e privilégios elevados. |
| Prioridade | Inventariar dispositivos Qualcomm afetados, acompanhar correções de firmware, restringir chamadas privilegiadas ao TEE e monitorar falhas de trustlets em logs de núcleo e telemetria de sistema. |
| Versões | Falha observada no Nexus 6 com Android 7.1.2 N6F27M e reproduzida em Moto G4/G4 Plus XT1643 e XT1640. |
| Artefatos | QSEOS, libQSEEComAPI.so, cmnlib.so, arquivos ELF assinados de trustlets, região física secapp e manipuladores de comando. |
| Mitigação | Aplicar atualizações do fabricante, revisar dependência de ROMs antigas, tratar crashes de TEE como eventos de segurança e limitar superfícies que conversam com trustlets. |
A análise descreve um caminho para testar aplicativos confiáveis Qualcomm executados sobre ARM TrustZone, com foco no QSEE, uma implementação de Trusted Execution Environment usada em dispositivos Android baseados em processadores Qualcomm. O TrustZone separa o processamento em Mundo Normal e Mundo Seguro, permitindo que componentes sensíveis, como serviços de chaves, DRM, reconhecimento biométrico e descriptografia de mídia, operem em uma área isolada por controles de hardware. Esse isolamento aumenta a importância de qualquer falha no TEE: o código roda com permissões elevadas e protege materiais que o sistema operacional principal não deveria acessar diretamente.
O ponto central é que cada trustlet recebe dados do Mundo Normal por meio de manipuladores de comando. Esses manipuladores normalmente interpretam um identificador de comando no início do buffer e, em seguida, processam argumentos adicionais conforme a função solicitada. Como um trustlet pode aceitar muitas chamadas externas, a superfície de parsing é relevante para fuzzing orientado por cobertura. O trabalho demonstrou uma forma de emular o manipulador de comandos em ambiente Android, adaptar o fluxo de chamadas ao QSEOS e usar instrumentação para gerar entradas variadas sem depender de testes manuais em cada caminho de código.
No QSEE, um trustlet Qualcomm é um arquivo ELF assinado, estendido por uma tabela de hashes usada na validação de integridade. Durante o carregamento, o QSEOS verifica a cadeia de certificados, valida a assinatura do bloco de hash e compara os hashes SHA-256 do cabeçalho e dos segmentos com os valores atestados. A biblioteca Android libQSEEComAPI.so participa da montagem dos arquivos que formam o trustlet antes do carregamento. Depois disso, o código e os dados são posicionados na região física secapp, inacessível ao Mundo Normal, e bibliotecas do Mundo Seguro, como cmnlib.so, podem ser carregadas e vinculadas ao trustlet.
Para permitir fuzzing, a pesquisa descreve a emulação do manipulador de comandos do trustlet fora do fluxo convencional do Mundo Seguro. O modelo depende de localizar segmentos de código e dados, reproduzir a disposição de memória esperada pelo binário e tratar chamadas de sistema do QSEOS que o trustlet faria durante a execução. Como essas chamadas não existem diretamente no processo Android comum, a abordagem envolve redirecionamento controlado para um trustlet alterado no Mundo Seguro e adaptação do QEMU para reconhecer instruções ARM específicas de chamada de sistema. O objetivo defensivo é obter cobertura de código e observar crashes sem publicar uma cadeia operacional de exploração.
A parte mais sensível da técnica está na quebra temporária da premissa de integridade para fins de laboratório. A cadeia de inicialização segura autentica SBL, bootloader, partição TrustZone e trustlets, impedindo alteração legítima de componentes do TEE mesmo com root no Android. No cenário analisado, a pesquisa usou uma cadeia de falhas de dia 1, identificada por CVE-2015-6639 e CVE-2016-2431, em Nexus 6 com builds Android antigos até MOB30D para alterar dados envolvidos na verificação. O efeito relevante para defesa é que o hash block validado pôde ser substituído antes da autenticação final dos segmentos, permitindo carregar um trustlet modificado em ambiente controlado.
Com esse arranjo, o fuzzing foi aplicado ao trustlet prov. O manipulador desse trustlet aceita comandos na faixa 0x70001 a 0x7000F, e o fuzzer encontrou um crash associado ao comando 0x7000D quando o primeiro argumento ultrapassa 9999. O contexto não estabelece execução de código, exfiltração, persistência ou exploração ativa dessa falha; o impacto confirmado é a condição de crash reproduzível no componente confiável. Ainda assim, em TEE, falhas de parsing merecem tratamento rigoroso porque o código opera em uma zona de privilégio e isolamento que protege chaves, estado de inicialização e dados sensíveis.
A superfície exposta não é uma API pública comum da aplicação Android, mas a ponte restrita entre serviços privilegiados do sistema e trustlets no TEE. O Mundo Normal normalmente limita acesso a componentes como DRM, serviços de mídia e keystore, mas esses serviços continuam enviando buffers estruturados ao Mundo Seguro. Se um desses caminhos aceitar entrada controlada indiretamente por aplicativo, mídia, conta, periférico ou fluxo de sistema, o trustlet passa a depender da robustez do seu parser interno. A criticidade vem da combinação de código proprietário, pouca observabilidade e privilégios altos no lado seguro.
O trustlet prov é o exemplo concreto da falha encontrada. A ocorrência foi indicada no Nexus 6 com a ROM oficial Android 7.1.2 N6F27M e também em Moto G4/G4 Plus, modelos XT1643 e XT1640. A pesquisa também mostra que trustlets e bibliotecas como cmnlib.so ficam concentrados na região secapp, com dados e código carregados em endereços físicos protegidos. Para operadores, isso significa que a análise de impacto precisa combinar inventário de modelo, versão de firmware, implementação TEE e serviços Android com permissão para conversar com o QSEE.
Ambientes móveis corporativos, laboratórios de firmware, equipes de produto Android e times de resposta que lidam com dispositivos Qualcomm devem tratar trustlets como componentes de segurança de baixo nível. A ausência de código-fonte e a dependência de assinaturas do fabricante dificultam mitigação local por configuração. Quando há suspeita de falha em TEE, a ação prática tende a depender de atualização de firmware, troca de build, bloqueio de dispositivos fora de suporte e coleta de evidências de crash para encaminhamento ao fabricante.
- Dispositivos Android baseados em Qualcomm com QSEE e trustlets assinados carregados pelo QSEOS.
- Nexus 6 com Android 7.1.2 N6F27M para a falha reproduzível no
prov. - Moto G4/G4 Plus XT1643 e XT1640 como modelos em que a condição também foi reproduzida.
- Serviços privilegiados do Android que enviam comandos ao TEE, como keystore, mídia e DRM.
A detecção deve se concentrar em sinais de instabilidade do TEE, reinicializações inesperadas, falhas de serviços que dependem do QSEE e mensagens do núcleo relacionadas à região secapp, carregamento de trustlets e comunicação com o Mundo Seguro. Como o TEE é opaco para ferramentas tradicionais de EDR em Android, a telemetria de valor costuma aparecer em logs de sistema, logs de núcleo, eventos de falha de serviços privilegiados e diferenças de comportamento após operações que exigem chaves, DRM, biometria ou mídia protegida. Em dispositivos gerenciados, a correlação com modelo, build e patch level é essencial.
O hunting não deve procurar apenas IoCs de rede, porque o caso descrito é uma falha local de parsing e emulação de trustlet, não uma campanha com infraestrutura maliciosa. A evidência defensiva mais útil é a sequência: processo privilegiado solicita operação ao QSEE, o trustlet processa comando, ocorre crash ou falha no serviço dependente, e o dispositivo registra instabilidade associada ao TEE. Em laboratório, entradas de fuzzing devem ser tratadas como dados de teste controlados, sem circulação em ambiente de produção. Em frota real, qualquer repetição de falhas em serviços ligados ao TEE deve ser escalada como possível problema de firmware.
Equipes de engenharia podem criar testes negativos internos para validar limites de argumentos aceitos por camadas que chamam trustlets, desde que esses testes não reproduzam payloads ofensivos nem dependam de exploração de cadeia de inicialização. A meta defensiva é confirmar que serviços de alto nível validam tamanhos, tipos e faixas antes de encaminhar buffers ao Mundo Seguro. Para DFIR, uma coleta mínima deve preservar versão da ROM, patch level, modelo exato, horário dos crashes, logs de núcleo disponíveis e sequência de ações do usuário ou serviço antes da falha.
- Mensagens de núcleo ou sistema associadas a carregamento de trustlets, região
secapp, QSEOS ou falhas de comunicação com QSEE. - Crashes de serviços privilegiados que dependem de keystore, DRM, mídia protegida ou funções biométricas.
- Reinicializações, travamentos ou perda temporária de funções sensíveis após operações que acionam o TEE.
- Diferenças por modelo, build Android, firmware do fabricante e nível de atualização de segurança.
A mitigação mais importante é manter firmware e sistema operacional atualizados, porque trustlets, QSEOS e bibliotecas do Mundo Seguro não são componentes que uma organização consiga corrigir isoladamente em produção. Dispositivos fora de suporte, especialmente modelos antigos com builds conhecidos por permitir pesquisa baseada em falhas de dia 1, devem ser removidos de ambientes que processem dados sensíveis ou usados apenas em laboratório isolado. Para frotas corporativas, políticas de MDM devem exigir patch level mínimo, bloquear desbloqueio de bootloader quando aplicável e registrar inventário detalhado de modelo e versão.
Na engenharia de produto, serviços do Mundo Normal que chamam o TEE devem validar entradas antes do envio, incluindo tamanho de buffer, identificador de comando, faixas numéricas e estados esperados. Essa validação não substitui correção no trustlet, mas reduz a chance de que dados não confiáveis cheguem ao componente privilegiado. Para fornecedores e equipes de firmware, fuzzing orientado por cobertura em trustlets é uma prática útil porque exercita parsers proprietários que raramente recebem a mesma visibilidade de código de aplicações comuns. O valor está em encontrar crashes, limites incorretos e inconsistências antes que o componente seja distribuído em larga escala.
Na resposta a incidentes, a presença de falha no TEE deve ser tratada como evento de alta sensibilidade, mesmo quando o impacto observado for apenas crash. A equipe deve evitar conclusões não sustentadas, como vazamento ou execução remota, se a evidência disponível mostrar somente instabilidade local. O caminho adequado é preservar telemetria, confirmar reprodutibilidade em dispositivo de teste, verificar boletins e imagens do fabricante, aplicar atualização quando disponível e, se necessário, isolar temporariamente modelos afetados de fluxos que dependam de chaves, autenticação biométrica ou conteúdo protegido.
- Atualizar firmware, ROM e patches de segurança fornecidos pelo fabricante para dispositivos Qualcomm afetados.
- Retirar de produção dispositivos antigos ou sem suporte que dependam de TrustZone para dados sensíveis.
- Validar argumentos e tamanhos nas camadas Android que chamam trustlets antes de encaminhar buffers ao QSEE.
- Monitorar crashes de serviços associados ao TEE e correlacionar com modelo, build e patch level.
- Escalar falhas reproduzíveis ao fabricante com logs, versão exata e descrição defensiva do impacto.
0 Comentários