Segurança microarquitetônica do AWS Firecracker VMM: análise de ataques e defesas microarquitetônicas

Tabela de links

• Resumo e Introdução
• Fundo
• Modelos de ameaças
• Análise dos Sistemas de Contenção do Firecracker
• Análise de Ataques e Defesas Microarquitetônicas em Microvms Firecracker
• Conclusão, agradecimentos e referências

5. ANÁLISE DE ATAQUES E DEFESAS MICROARQUITETÔNICAS EM MICROVMS DE FOGUETES

Nesta seção, apresentamos nossa análise de uma série de canais laterais de microarquitetura e PoCs de ataque especulativo em microVMs Firecracker. Testamos esses PoCs em bare metal e em instâncias do Firecracker, e testamos defesas de microcódigo relevantes em vários cenários. Executamos nossos testes em um servidor com CPU Intel Skylake 4114

que possui extensões de hardware de virtualização e SMT habilitado. A CPU funciona na versão do microcódigo 0x2006b06[2]. O sistema operacional host é Ubuntu 20.04 com kernel Linux 5.10. Usamos Firecracker v1.0.0 e v1.4.0, a versão mais recente em julho de 2023, para executar um convidado Ubuntu 18.04 com kernel Linux 5.4 que é fornecido pela Amazon ao seguir o guia de início rápido[3].

Em resumo, a configuração recomendada do host de produção fornecida com o AWS Firecracker é insuficiente quando se trata de proteger os locatários contra vizinhos mal-intencionados. A Firecracker, portanto, falha em fornecer as garantias de isolamento reivindicadas. Isto é porque

(1) identificamos uma variante Medusa que só se torna explorável quando executada em microVMs. Além disso, as contramedidas recomendadas não contêm as medidas necessárias para mitigar o canal lateral ou a maioria das outras variantes da Medusa.

(2) mostramos que os locatários não estão devidamente protegidos contra vazamentos de informações induzidos através do Spectre-PHT ou Spectre-BTB ao aplicar as contramedidas recomendadas. As variantes Spectre-PHT continuam sendo um problema mesmo ao desativar o SMT.

(3) não observamos diferenças no desempenho do PoC entre Firecracker v1.0.0 e v1.4.0.

Concluímos que a camada de virtualização fornecida pelo Firecracker tem pouco efeito sobre ataques microarquiteturais e que as recomendações de segurança do sistema do Firecracker são insuficientes.

5.1 Medusa

Avaliamos os PoCs de Moghimi [35] para os canais laterais Medusa [37] (classificados pela Intel como variantes MLPDS do MDS [25]) no bare metal de nosso sistema de teste e em VMs Firecracker. Há um PoC vazando para cada uma das três variantes conhecidas descritas na seção 2.4.2. Usamos dois programas vítimas da biblioteca PoC:

• O programa “Block Write” grava uma grande quantidade de dados consecutivos em um loop (para que o processador identifique armazenamentos repetidos e os combine).

• O programa “REP MOV” executa uma operação semelhante, mas com a instrução REP MOV em vez de muitas instruções movendo blocos menores de dados em um loop.

5.1.1 Resultados. A Tabela 1 mostra os casos em que os dados vazaram com sucesso com todas as proteções de microarquitetura no kernel desativadas. As duas colunas à esquerda mostram as combinações possíveis dos três PoCs da Medusa e dos dois programas de vítimas incluídos. As colunas da direita indicam quais configurações funcionam em bare metal e com o programa secreto e com vazamento sendo executado em instâncias paralelas do Firecracker. Mais notavelmente, com a variante Cache Indexing, o segredo Block Write só funciona com o Firecracker. Provavelmente, isso se deve à virtualização do endereço de memória que a máquina virtual fornece: o convidado vê apenas regiões de memória virtual mapeadas pelo KVM, e o KVM captura instruções de acesso à memória e manipula as transações em nome do convidado.

Testamos a eficácia das defesas mds e nosmt contra cada combinação de PoC de atacante e vítima em bare metal e em VMs Firecracker. A Tabela 2 lista as proteções necessárias para evitar ataques Medusa em cenários bare metal e Firecracker. Entre as quatro vulnerabilidades do Firecracker, apenas uma é mitigada apenas pelo nosmt, e a AWS não recomenda explicitamente ativar a proteção mds, embora a maioria das distribuições Linux seja fornecida com ela habilitada por padrão. Ou seja, uma plataforma de nuvem multilocatário poderia usar o Firecracker de uma forma compatível com as medidas de segurança recomendadas pela AWS e ainda ser vulnerável à maioria das variantes do Medusa, incluindo uma em que o próprio VMM do Firecracker vaza os dados do usuário que iriam caso contrário, não será vazado.

5.2 RIDL e mais

Nesta seção, apresentamos uma avaliação dos programas RIDL PoC [51] fornecidos juntamente com o artigo de 2019 de van Schaik et al. RIDL é uma classe de ataques MDS que explora cargas especulativas de buffers dentro da CPU (não de cache ou memória). O repositório RIDL PoC também inclui exemplos de ataques divulgados em adendos posteriores ao artigo, bem como uma variante do ataque Fallout MDS.

5.2.1 Resultados. A Tabela 3 mostra algumas informações básicas sobre os PoCs RIDL que testamos e a eficácia das contramedidas relevantes na prevenção dos ataques. Comparamos ataques em bare metal e no Firecracker para avaliar as afirmações da Amazon sobre maior segurança de hardware do sistema microVM Firecracker. Para testes no sistema Firecracker, distinguimos entre sinalizadores de contramedidas habilitados no sistema host (H) e no kernel convidado (VM) do Firecracker. Além dos sinalizadores de kernel nosmt e mds, testamos outros sinalizadores relevantes (cf. seção 2.4.4, [21]), incluindo kaslr, pti e l1tf, mas não descobrimos que eles afetassem qualquer um desses programas. Excluímos a mitigação tsx_async_abort, pois a CPU em que testamos inclui a mitigação mds, o que torna o sinalizador do kernel tsx_async_abort redundante [20].

Em geral, descobrimos que a proteção mds não protege adequadamente contra a maioria dos ataques RIDL. No entanto, desabilitar o SMT atenua a maioria dessas explorações. Isso é consistente com as declarações da Intel [25] e dos desenvolvedores do Linux [21] de que o SMT deve ser desabilitado para evitar ataques MDS em hyperthreads. Os dois valores discrepantes entre esses PoCs são alinhamento_write, que requer nosmt e mds no host, e pgtable_leak_notsx, que é mitigado apenas por contramedidas mds. O vazamento baseado em alinhamento_write usa uma falha de alinhamento em vez de um vazamento de falha na tabela de páginas para desencadear especulação [50]. O artigo RIDL [50] e a documentação da Intel sobre a exploração VRS relacionada [26] não são claros sobre o que exatamente diferencia este ataque dos ataques MFBDS baseados em falhas de página encontrados em outros PoCs, mas nossas descobertas experimentais indicam que o mecanismo microarquitetural do vazamento é distinto. Há uma explicação simples e razoável para o comportamento de pgtable_leak_notsx, que é único entre esses PoCs por um motivo principal: é o único exploit que ultrapassa os limites de segurança (vazando valores da tabela de páginas do kernel) dentro de um único thread, em vez de vazar de outro tópico. É evidente que desabilitar o multi-threading teria pouco efeito nesta exploração de thread único. No entanto, a contramedida mds libera buffers de microarquitetura antes de mudar da execução de privilégio de kernel para execução de privilégio de usuário dentro do mesmo thread, limpando os dados da tabela de páginas acessados pelo código do kernel do LFB antes que o código do usuário atacante possa vazá-los.

Em contraste com a Medusa, a maioria desses PoCs são atenuados pela recomendação da AWS de desabilitar o smt. No entanto, como acontece com o Medusa, o próprio VMM Firecracker não oferece proteção microarquitetural contra esses ataques.

5.3 Espectro

A seguir, nos concentraremos nas vulnerabilidades do Spectre. Embora muitas contramedidas tenham sido desenvolvidas desde a descoberta dos ataques Spectre, muitas delas acarretam uma penalidade de desempenho (significativa) ou atenuam apenas parcialmente o ataque. Portanto,

os operadores de sistema muitas vezes precisam decidir entre desempenho e segurança. Nesta seção, avaliamos a superfície de ataque Spectre disponível para locatários do Firecracker em ambos os modelos de ameaça descritos anteriormente. Para avaliar a ampla gama de ataques Spectre, contamos com os PoCs fornecidos em [15]. Para Spectre-PHT, Spectre-BTB e SpectreRSB, o repositório contém quatro PoCs cada. Eles diferem na forma como o invasor maltrata o BPU. As quatro possibilidades são (1) mesmo processo – o invasor tem controle sobre o processo da vítima ou suas entradas para distorcer a BPU – (2) processo cruzado – o invasor executa seu próprio código em um processo separado para influenciar as previsões de ramificação do o processo da vítima – (a) no local – o invasor treina mal o BPU com instruções de ramificação que residem no mesmo endereço virtual da ramificação alvo que o invasor deseja que seja mal previsto no processo da vítima – (b) fora de local – o invasor maltrata a BPU com instruções de ramificação que residem em endereços que são congruentes com as ramificações alvo no processo da vítima.

(1) mesmo processo: o invasor tem controle sobre o processo da vítima ou suas entradas para distorcer o BPU,

(2) processo cruzado: o invasor executa seu próprio código em um processo separado para influenciar as previsões de ramificação do processo da vítima,

(3) no local: o invasor treina mal a BPU com instruções de ramificação que residem no mesmo endereço virtual da ramificação alvo que o invasor deseja que seja mal prevista no processo da vítima

(4) fora do lugar: o invasor maltrata a BPU com instruções de ramificação que residem em endereços congruentes com as ramificações alvo no processo da vítima.

As duas primeiras e as duas últimas situações são ortogonais, portanto cada PoC combina duas delas. Para Spectre-STL, apenas variantes do mesmo processo são conhecidas, razão pela qual o repositório fornece apenas dois PoCs neste caso. Para experimentos entre VMs, desabilitou a randomização do layout do espaço de endereço para os kernels host e convidado, bem como para o nível de usuário host e convidado, para facilitar a localização de endereços congruentes que são usados para treinamento incorreto.

5.3.1 Resultados. Com as contramedidas recomendadas pela AWS [8] (o padrão para os kernels Linux em uso, cf. Figura 5) habilitadas no sistema host e dentro das VMs do Firecracker, vemos que o Spectre-RSB é mitigado com sucesso tanto no host quanto dentro e entre VMs (cf. Tabela 4). Por outro lado, Spectre-STL, Spectre-BTB e Spectre-PHT permitiram vazamento de informações em situações particulares.

Os PoCs para Spectre-STL mostram vazamento. Porém, o vazamento ocorre apenas dentro do mesmo processo e no mesmo nível de privilégio. Como não são conhecidas variantes de processo cruzado, não testamos o cenário crossVM para Spectre-STL. Em nosso modelo de ameaça de usuário para usuário, o Spectre-STL não é um possível vetor de ataque, pois nenhuma variante entre processos é conhecida. Se duas cargas de trabalho de locatário fossem isoladas por isolamento em processo dentro da mesma VM, o Spectre-STL ainda poderia ser um vetor de ataque viável. No modelo usuário-host, o Spectre-STL é mitigado por contramedidas incluídas nos kernels Linux atuais e habilitadas por padrão.

Para Spectre-PHT, as contramedidas do kernel incluem a higienização de ponteiros de usuário e a utilização de barreiras (lfence) em switches de nível de privilégio. Concluímos, portanto, que o SpectrePHT representa pouca ou nenhuma ameaça ao sistema host. No entanto, estes

as mitigações não protegem dois hyperthreads um do outro se eles forem executados no mesmo núcleo físico em paralelo. É por isso que todas as quatro variantes de treinamento incorreto do Spectre-PHT são totalmente funcionais no sistema host, bem como dentro das VMs do Firecracker. Como pode ser visto na Tabela 4, isso permanece verdadeiro mesmo se o SMT estiver desabilitado[4]. Na verdade, fixar ambas as VMs no mesmo thread físico permite a versão fora do local de processo cruzado do Spectre-PHT, enquanto não observamos vazamento no caso SMT. Isso torna o Spectre-PHT uma ameaça significativa para usuário a usuário.

Os PoCs Spectre-BTB são parcialmente funcionais quando as contramedidas recomendadas pela AWS estão habilitadas. A variante original que deforma o BTB no mesmo processo e no mesmo endereço é totalmente funcional, enquanto a deformação fora do lugar no mesmo processo é

mitigados com sucesso. Além disso, todas as tentativas de vazar informações através dos limites do processo por meio de treinamento incorreto fora do local não mostraram nenhum vazamento. Com o mau treinamento no local do processo cruzado, entretanto, observamos vazamentos. No sistema host, o vazamento ocorreu independentemente do SMT. Dentro de uma VM, o vazamento só ocorreu se todos os núcleos virtuais da CPU fossem atribuídos a um thread físico separado. Nas VMs, a desativação do SMT removeu o vazamento.

Além das contramedidas listadas na Figura 5, o kernel do host possui contramedidas Spectre compiladas no ponto de entrada e saída da VM[5] para impedir totalmente que convidados mal-intencionados ataquem o kernel do host enquanto o kernel lida com uma saída da VM.

Em resumo, podemos dizer que as contramedidas padrão do Linux – recomendadas pelo AWS Firecracker – mitigam apenas parcialmente o Spectre. Precisamente, mostramos:

• Spectre-PHT e Spectre-BTB ainda podem vazar informações entre locatários no cenário de convidado para convidado com as contramedidas recomendadas pela AWS, que incluem a desativação do SMT, em vigor.

• O kernel do host provavelmente está suficientemente protegido pelas precauções adicionais compiladas no kernel do Linux para proteger as entradas e saídas da VM. Isto, no entanto, é ortogonal às medidas de segurança fornecidas pelo Firecracker.

Todos os vazamentos observados foram independentes da versão do Firecracker em uso.

5.3.2 Avaliação. Descobrimos que o Firecracker não aumenta as mitigações contra o Spectre, mas depende apenas de recomendações gerais de proteção, que incluem mitigações fornecidas pelos kernels host e convidado e atualizações opcionais de microcódigo. Pior ainda, as contramedidas recomendadas protegem insuficientemente os aplicativos sem servidor contra o vazamento de informações para outros locatários. Portanto, afirmamos que o Firecracker não atinge seu objetivo de isolamento no nível microarquitetural, embora os ataques microarquiteturais sejam considerados dentro do escopo do modelo de ameaça do Firecracker.

O leitor de alerta pode se perguntar por que o Spectre-BTB continua sendo um problema com a contramedida STIBP em vigor (cf. Figura 5), já que esse patch de microcódigo foi projetado para impedir que a previsão de ramificação use informações de previsão originadas de outro thread. Isso também nos intrigou por um tempo, até recentemente o Google publicou um comunicado de segurança[6] que identifica uma falha no Linux 6.2 que desativava a mitigação do STIBP quando o IBRS estava habilitado. Verificamos que a seção de código identificada como responsável pelo problema também está presente no código-fonte do Linux 5.10. Nossa suposição, portanto, é que o mesmo problema identificado pelo Google também ocorre em nosso sistema.

[2] A atualização do microcódigo para uma versão mais recente desativaria o TSX em nosso sistema, o que impossibilitaria os testes com variantes do MDS baseadas em TSX.

[3] https://github.com/firecracker-microvm/firecracker/blob/dbd9a84b11a63b5e5bf201e244fe83f0bc76792a/docs/getting-started.md

[4] Isso é simulado fixando o processo do atacante e da vítima no mesmo núcleo ((1PT))

[5] https://elixir.bootlin.com/linux/v5.10/source/arch/x86/kvm/vmx/vmenter.S#L191

[6] https://github.com/google/security-research/security/advisories/GHSA-mj4w6495-6crx