.
Chapéu preto Pesquisadores de segurança de computadores do Centro Helmholtz de Segurança da Informação da CISPA, na Alemanha, encontraram sérias falhas de segurança em alguns processadores RISC-V da subsidiária da Alibaba, T-Head Semiconductor.
O mais sério deles, que afeta os quatro núcleos da CPU T-Head C910 no SoC TH1520, foi apelidado de GhostWrite porque permite que um aplicativo ou usuário desonesto leia e grave na memória física e execute código arbitrário com privilégios de kernel (supervisor) e modo máquina, permitindo que eles assumam o controle total do dispositivo.
O cenário de ameaça assume que o invasor não tem privilégios, mas é capaz de executar código nativo no hardware afetado. Portanto, ele se aplicaria a malware que entra em um sistema vulnerável e clientes que executam máquinas virtuais ou contêineres em hardware vulnerável, permitindo que eles sequestrem totalmente o host, mas não para um invasor remoto.
A vulnerabilidade está em instruções defeituosas na implementação de extensão vetorial do C910, adicionadas para permitir o processamento de valores de dados maiores e específicas para aquele design de CPU. O problema é que algumas dessas instruções operam na memória física em vez da memória virtual, o que desfaz qualquer isolamento que esteja em vigor para manter o sistema operacional e os aplicativos separados.
Sim, é isso mesmo: ao usar essas instruções falhas, você estará tocando diretamente na memória física, ignorando a MMU e seus mecanismos de proteção de memória que normalmente impedem que os aplicativos interfiram entre si e com o sistema operacional e hardware subjacentes.
E como as instruções são embutidas no silício, elas não podem ser corrigidas com um microcódigo ou atualização de software. Para mitigar o problema, a extensão do vetor deve ser desabilitada. Fazer isso significa que os aplicativos que dependem dessas instruções do vetor quebrarão e, se emulados no software para continuar funcionando, sofrerão impactos de desempenho punitivos.
Os pesquisadores que detectaram tudo isso – Fabian Thomas, Lorenz Hetterich, Ruiyi Zhang, Daniel Weber, Lukas Gerlach e Michael Schwarz – devem apresentar suas descobertas na conferência de segurança Black Hat em Las Vegas, Nevada, na quarta-feira.
Eles também publicaram um site, ghostwriteattack.com, e um artigo técnico intitulado “RISCVuzz: Descobrindo vulnerabilidades arquitetônicas de CPU por meio de fuzzing diferencial de hardware”.
RISC-V é uma arquitetura de conjunto de instruções (ISA) de padrão aberto. Diferentemente de outras ISAs mais amplamente utilizadas, como x86 e Arm, ela está disponível sem royalties e qualquer um é bem-vindo para contribuir com ela.
Os designers de chips podem pegar as especificações do ISA e usá-las para projetar suas próprias CPUs compatíveis com RISC-V, e podem escolher suportar extensões opcionais para adicionar funcionalidade aos seus núcleos. Assim, os problemas de segurança aqui com o C910 estão na implementação do ISA da própria T-Head, especificamente sua implementação não padrão da extensão vetorial, e não nas especificações em si nem em outros chips RISC-V.
Essa abertura e extensibilidade tornaram o RISC-V popular entre os fornecedores, observam os especialistas em Helmholtz da CISPA em seu artigo. Mas o resultado tem sido uma gama crescente de implementações de hardware com recursos e medidas de segurança variados – e suas próprias falhas de segurança.
Para avaliar melhor o comportamento e as características do chip, os pesquisadores desenvolveram uma estrutura de fuzzing chamada RISCVuzz, que usa uma variedade de implementações RISC-V para executar fuzzing diferencial. A ferramenta de teste assume que o resultado arquitetônico de cada instrução deve ser o mesmo em diferentes CPUs e sinaliza instâncias onde o comportamento é diferente.
Os pesquisadores usaram o RISCVuzz em cinco designs de núcleo de CPU RISC-V atualmente disponíveis executando Linux de 64 bits: T-Head XuanTie C906/C908/C910 e SiFive U54/U74. Eles encontraram três vulnerabilidades arquitetônicas de CPU dentro dos chips T-Head, sem mencionar outros bugs que causam falhas de segmentação nas duas últimas versões principais do QEMU.
A vulnerabilidade mais grave, GhostWrite, afeta o C910 no SoC TH1520 e permite que usuários sem privilégios gravem qualquer coisa na memória sem se preocupar com recursos de segurança e isolamento.
“O ataque é 100% confiável, determinístico e leva apenas microssegundos para ser executado”, explica o site GhostWrite. “Mesmo medidas de segurança como a conteinerização do Docker ou sandboxing não conseguem impedir esse ataque. Além disso, o invasor pode sequestrar dispositivos de hardware que usam entrada/saída mapeadas em memória (MMIO), permitindo que eles enviem quaisquer comandos para esses dispositivos.”
Explorá-lo é tão simples quanto executar a seguinte sequência de instruções:
vsetvli zero, zero, e8, m1 vmv.v.x v0, a0 vse128.v v0, 0(t0)
Onde o registrador t0 contém o endereço de memória física que você quer escrever, mesmo que não tenha permissão para isso, e a0 o byte que você quer escrever; e isso simplesmente acontece. A implementação do T-Head de sua instrução vse128.v não padrão é quebrada, pois não trata o endereço como virtual e, em vez disso, vai direto para a memória física, permitindo que qualquer aplicativo, incluindo malware, rabisque sobre o kernel do SO, ou hipervisor ou firmware de nível de máquina, e assuma o controle do dispositivo.
Além disso, no C910, ler do endereço virtual 0 se ele for apoiado por RAM física congela o núcleo da CPU independentemente do nível de privilégio até um ciclo de energia. Nossa.
Isso nos lembra do bug F00F da Intel da década de 1990, que travava o processador até uma reinicialização forçada, entre outros erros de chip cometidos pela indústria ao longo dos anos.
Há também duas vulnerabilidades afetando o T-Head XuanTie C906 e C908 descritas no artigo como vulnerabilidades de CPU do tipo “halt-and-catch-fire”. Elas permitem que um invasor sem privilégios trave a CPU. Esses bugs, se explorados, exigiriam uma reinicialização.
O artigo lista outras falhas nos projetos do T-Head, como instruções consideradas ilegais quando não deveriam, ou a geração do tipo errado de exceção.
O SoC TH1520 baseado em C910 é usado pela empresa francesa de nuvem Scaleway.
Os seguintes dispositivos também são considerados vulneráveis ao GhostWrite do C910:
Os especialistas em seu artigo observam que a Universidade de Shandong, na China, tem um cluster RISC-V com uma variante C910, embora não tenham conseguido determinar se essa variante é afetada.
Corrigir esses bugs não é fácil. Como dissemos, a única mitigação proposta para o GhostWrite é desabilitar a extensão de vetor defeituosa. Como os autores explicam, isso quebra aplicativos que usam instruções de vetor e adiciona uma sobrecarga de 77 por cento, conforme medido pelo rvv-bench.
“Para o bug que interrompe a CPU do C906, não encontramos nenhuma mitigação, já que a extensão do fornecedor responsável não pode ser desabilitada”, diz o artigo.
Os pesquisadores dizem que divulgaram suas descobertas ao T-Head do Alibaba, que reconheceu e reproduziu os bugs C910 e C906, embora ainda não tenha respondido ao relatório C908.
Michael Schwarz, docente do CISPA Helmholtz e um dos coautores do artigo, disse O registro“A Scaleway notificou os usuários sobre suas instâncias RISC-V, sugerindo atualizar o kernel devido a vulnerabilidades de segurança. Isso é algo que os usuários precisam fazer manualmente. Até onde eu sei, essa atualização do kernel desabilita as extensões de vetor.”
Ironicamente, é a natureza de “conjunto de instruções reduzido” das implementações RISC-V que limita as opções de soluções alternativas, porque os processadores RISC-V geralmente disponíveis hoje em dia, até onde sabemos, não usam microcódigo reprogramável para operar — o que significa que não é possível carregar uma atualização em tempo de execução para corrigir instruções quebradas e adicionar funcionalidade.
“A complexidade do x86 ISA requer uma camada de ‘firmware’ (ou seja, o microcódigo) para suportar algumas das instruções muito complexas”, explicou Schwarz. “Um efeito colateral disso é que o comportamento dessas instruções também pode ser alterado com uma atualização de microcódigo. Além disso, as atualizações de microcódigo permitem a introdução de novos recursos para contornar vulnerabilidades.
“Vimos que para vulnerabilidades em CPUs Intel, como ZombieLoad: Uma atualização de microcódigo adicionou um novo recurso para liberar buffers internos. Embora isso não tenha corrigido a vulnerabilidade, garantiu que não houvesse dados secretos para vazar.
“RISC-V tem apenas instruções simples que não exigem tal camada de ‘firmware’. Portanto, também não há possibilidade de adicionar novos recursos por meio de uma atualização. No entanto, seria possível também ter microcódigo no RISC-V, mas não estou ciente de nenhuma CPU RISC-V implementando isso.”
Mas isso é algo que Schwarz e seus coautores recomendam em seu artigo, com base na suposição de que o uso não regulamentado do RISC-V ISA e a possibilidade de extensões personalizadas de fornecedores levarão a mais vulnerabilidades desse tipo.
“Dada a crescente complexidade das CPUs RISC-V, defendemos essa camada de microcódigo no RISC-V para ter a possibilidade de mitigar vulnerabilidades da CPU”, conclui o artigo. ®
.
