Autores:  (1) Zane Weissman, Instituto Politécnico de Worcester Worcester, MA, EUA {zweissman@wpi.edu};  (2) Thomas Eisenbarth, Universidade de Lübeck Lübeck, SH, Alemanha {thomas.eisenbarth@uni-luebeck.de};  (3) Thore Tiemann, Universidade de Lübeck Lübeck, SH, Alemanha {t.tiemann@uni-luebeck.de};  (4) Berk Sunar, Instituto Politécnico de Worcester Worcester, MA, EUA {sunar@wpi.edu}.  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.     . 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. KVM    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. Metadados, dispositivos e serviços de E/S.  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.    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]. Barreira do carcereiro.  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.  Este artigo está   sob licença CC BY-NC-ND 4.0 DEED. disponível no arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

AutoEncoder.tech

Research & publications on Auto Encoders, revolutionizing data compression and feature learning techniques.

Auto Encoder's blog

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps