Segurança microarquitetônica do AWS Firecracker VMM: análise dos sistemas de contenção do Firecracker

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

4. ANÁLISE DOS SISTEMAS DE CONTENÇÃO DE FOGUETES

A Figura 2 mostra a contenção oferecida pelo Firecracker, conforme apresentada pela AWS. Nesta seção, analisamos cada componente representado e suas defesas e vulnerabilidades a ataques de microarquitetura.

KVM . A máquina virtual baseada em kernel Linux (KVM) é o hipervisor implementado em kernels Linux modernos e, portanto, parte da base de código do Linux. Ele virtualiza os modos de supervisor e usuário do hardware subjacente, gerencia alternâncias de contexto entre VMs e lida com a maioria dos motivos de saída de VM, a menos que estejam relacionados a operações de E/S. Além desses mecanismos de isolamento arquitetônico, o KVM também implementa mitigações contra ataques Spectre em uma saída de VM para proteger o sistema operacional host ou hipervisor contra convidados mal-intencionados. O Firecracker depende fortemente do KVM como hipervisor. No entanto, como o KVM faz parte do código-fonte do Linux e é desenvolvido pela comunidade Linux, definimos o KVM como não fazendo parte do Firecracker. Portanto, as contramedidas contra ataques microarquiteturais implementadas no KVM não podem ser atribuídas ao sistema de contenção do Firecracker.

Metadados, dispositivos e serviços de E/S. Os metadados, dispositivos e serviços de E/S são as partes do Firecracker VMM e da API que interagem diretamente com uma VM, coletando e gerenciando métricas e fornecendo conectividade. A AWS apregoa a simplicidade dessas interfaces (para uma superfície de ataque reduzida) e que elas foram escritas do zero para Firecracker em Rust, uma linguagem de programação conhecida por seus recursos de segurança [9]. No entanto, Rust fornece proteção durante o processo contra acessos de memória inválidos e fora dos limites, mas ataques de microarquitetura como ataques de cache, Spectre e MDS podem vazar informações entre processos em vez de sequestrar diretamente o processo da vítima.

Outra diferença notável entre o Firecracker e muitos outros VMMs é que todos esses serviços são executados no mesmo processo host que a própria VM, embora em outro thread. Embora a virtualização de endereços de memória na VM forneça alguma ofuscação entre o código do convidado e os serviços de E/S, alguns ataques Spectre funcionam especificamente em um único processo. No entanto, os ataques intraprocessos podem representar uma ameaça menor aos sistemas do mundo real, uma vez que dois convidados rodando no mesmo hardware têm, cada um, sua própria cópia desses serviços essenciais.

Barreira do carcereiro. Caso a API ou o VMM sejam comprometidos, o jailer fornece uma última barreira de defesa em torno de uma instância do Firecracker. Ele protege os arquivos e recursos do sistema host com namespaces e grupos de controle (cgroups), respectivamente [7]. Os ataques microarquiteturais não ameaçam diretamente os arquivos, que estão, por definição, fora do estado microarquitetural. Cgroups permitem que um administrador de sistema atribua processos a grupos e então aloque, restrinja e monitore o uso de recursos do sistema por grupo [17]. É plausível que as limitações aplicadas aos cgroups possam impedir a capacidade de um invasor de realizar certos ataques microarquiteturais. Por exemplo, as limitações de memória podem dificultar a realização de ataques de cache baseados em despejo, ou as limitações de tempo de CPU podem impedir que um invasor faça uso eficaz de uma ferramenta de negação de serviço de CPU como o HyperDegrade [2], que pode retardar a vítima. processo, simplificando o tempo de uma exfiltração ou injeção microarquitetônica de canal lateral. Na prática, o Firecracker não é distribuído com nenhuma regra específica do cgroup [7]; na verdade, ele foi projetado especificamente para a operação eficiente de muitas VMs do Firecracker sob a alocação de recursos padrão do Linux [6].

Nenhum dos sistemas de isolamento e contenção do Firecracker parece proteger diretamente contra ataques de usuário para usuário ou de usuário para host. Portanto, testamos várias provas de conceitos de ataque microarquiteturais dentro e fora das VMs do Firecracker.