CVE-2021-27562

Falha de out-of-bounds write (CWE-787) no Arm Trusted Firmware-M (TF-M), a implementação de referência da arquitetura TrustZone para microcontroladores Cortex-M. Código executando no mundo não-seguro (NSPE), em modo handler, pode corromper ou ler memória do mundo seguro (SPE) ao invocar funções seguras via SVC, causando halt do sistema, sobrescrita de dados seguros ou exfiltração deles. Está no catálogo KEV da CISA com exploração confirmada e afeta especificamente servidores Yealink Device Management, que embarcam TF-M.

TF-M implementa a separação entre Secure Processing Environment (SPE) e Non-Secure Processing Environment (NSPE) definida pelo TrustZone-M (ARMv8-M). Chamadas do lado não-seguro para funções seguras passam por uma instrução SVC, e o Secure Partition Manager do TF-M precisa buscar o stack pointer (SP) do chamador não-seguro para localizar argumentos e copiá-los para o lado seguro antes de processá-los.

O advisory do próprio projeto identifica isso como 'SVC caller SP fetching vulnerability': quando a chamada SVC ocorre em modo handler do NSPE (ou seja, dentro de uma exceção/interrupção não-segura, não em thread mode normal), a rotina do TF-M que determina qual SP usar para buscar os argumentos da chamada segura pode ser induzida a ler o SP errado ou um SP controlado pelo atacante. Como o SPM confia nesse ponteiro para calcular endereços de leitura/escrita na fronteira segura/não-segura, um valor de SP manipulado resulta em acesso fora dos limites (CWE-787) sobre memória do mundo seguro.

O atacante não precisa quebrar o isolamento de hardware do TrustZone — ele já está executando código no NSPE (que é, por definição, não confiável) e abusa de uma falha lógica na rotina de marshalling de argumentos entre os dois mundos. O que ele controla é o conteúdo do stack não-seguro e o timing/contexto da chamada (executar a SVC durante o tratamento de uma exceção não-segura), o que basta para deslocar a leitura do SP para fora da área esperada.

O pré-requisito real é ter capacidade de executar código arbitrário no lado não-seguro (NSPE) do dispositivo — isso normalmente significa comprometer o firmware/aplicação não-segura do produto, não um ataque remoto direto contra a rede. O vetor CVSS informado (AV:L, PR:L, UI:N) reflete justamente isso: acesso local ao ambiente de execução do dispositivo com privilégios baixos, sem interação do usuário.

Na prática, o atacante posiciona uma chamada SVC para uma função segura de forma que ela ocorra em modo handler (dentro de uma interrupção não-segura), manipulando previamente a pilha não-segura. Isso faz o SPM do TF-M calcular incorretamente o endereço dos argumentos da chamada segura, permitindo escrita fora dos limites em memória do lado seguro. Dependendo da função segura alvo e da estrutura de memória do firmware, o resultado vai de um halt do sistema (negação de serviço) até sobrescrita de dados seguros (potencial escalonamento de privilégio dentro do próprio TEE) ou impressão/retorno de dados seguros para o lado não-seguro (vazamento de segredos, chaves, etc.).

A CISA lista a CVE no catálogo KEV com exploração confirmada, associando-a especificamente a servidores Yealink Device Management, que embarcam TF-M vulnerável — indicando que existe exploração documentada em produto real, não apenas prova de conceito acadêmica.

TF-M é firmware embarcado compilado em produtos de terceiros; não há um pacote genérico para 'atualizar' — a correção depende do fornecedor do dispositivo (no caso confirmado pela CISA, Yealink) publicar firmware com TF-M corrigido. A ação recomendada pela própria CISA é 'aplicar atualizações conforme instruções do fornecedor', com prazo definido de 2021-11-17 para o KEV.

As versões afetadas descritas oficialmente vão 'through 1.2' do TF-M; as fontes disponíveis não trazem o número exato da versão/commit que introduz a correção — para confirmar o fix específico é necessário consultar o advisory do projeto TF-M (security_advisories/svc_caller_sp_fetching_vulnerability.rst) e o changelog da versão usada pelo fabricante do dispositivo.

Como paliativo, para quem mantém builds próprias de TF-M: revisar/atualizar a rotina de fetching do SP do chamador em chamadas SVC vindas de contexto handler mode do NSPE, conforme o patch upstream do projeto. Não há mitigação de rede ou WAF eficaz, pois a falha ocorre na fronteira de hardware/firmware dentro do próprio dispositivo — bloquear tráfego externo não impede exploração se o atacante já tiver execução de código no NSPE.

Não há assinatura de rede ou log de aplicação confiável para essa vulnerabilidade — a exploração ocorre inteiramente dentro do dispositivo, na fronteira entre firmware não-seguro e seguro, sem tráfego de rede associado ao próprio ataque. Sinais indiretos possíveis incluem halts/reboots inesperados do dispositivo (indicativo do efeito de negação de serviço descrito) ou comportamento anômalo de funções seguras específicas, mas esses sintomas não são exclusivos dessa CVE e exigem análise de firmware/depuração para confirmação.