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  ABSTRATO  Firecracker é um gerenciador de máquina virtual (VMM) desenvolvido especificamente pela Amazon Web Services (AWS) para plataformas de nuvem sem servidor – serviços que executam código para usuários finais por tarefa, gerenciando automaticamente a infraestrutura do servidor. O Firecracker fornece VMs rápidas e leves e promete uma combinação entre a velocidade dos contêineres, normalmente usados para isolar pequenas tarefas, e a segurança das VMs, que tendem a fornecer maior isolamento em detrimento do desempenho. Essa combinação de segurança e eficiência, afirma a AWS, torna não apenas possível, mas também seguro, executar milhares de tarefas de usuários diferentes no mesmo hardware, com o sistema host alternando rápida e frequentemente entre tarefas ativas. Embora a AWS afirme que os ataques de microarquitetura estão incluídos em seu modelo de ameaça, essa classe de ataques depende diretamente de hardware compartilhado, assim como a escalabilidade da computação sem servidor depende do compartilhamento de hardware entre um número sem precedentes de usuários.  Neste trabalho, investigamos o quão seguro o Firecracker é contra ataques microarquiteturais. Primeiro, revisamos o modelo de isolamento declarado do Firecracker e as práticas recomendadas para implantação, identificamos modelos de ameaças potenciais para plataformas sem servidor e analisamos possíveis pontos fracos. Em seguida, usamos provas de conceito de ataque microarquitetural para testar o isolamento fornecido pelo Firecracker e descobrimos que ele oferece pouca proteção contra ataques Spectre ou MDS. Descobrimos dois casos particularmente preocupantes: 1) uma variante Medusa que ameaça as VMs do Firecracker, mas não os processos executados fora delas, e não é mitigada pelas defesas recomendadas pela AWS, e 2) uma variante Spectre-PHT que permanece explorável mesmo se as contramedidas recomendadas estiverem em vigor. lugar e o SMT está desabilitado no sistema. Em resumo, mostramos que a AWS exagera a segurança inerente ao Firecracker VMM e fornece orientação incompleta para proteger adequadamente os sistemas em nuvem que usam o Firecracker.   CONCEITOS DE CCS   • Segurança e privacidade → Virtualização e segurança; Análise e contramedidas de canal lateral.   PALAVRAS-CHAVE  segurança do sistema, segurança microarquitetural, máquinas virtuais, hipervisor, sem servidor, sistemas em nuvem  1. INTRODUÇÃO  A computação sem servidor é uma tendência emergente na computação em nuvem, onde os provedores de serviços em nuvem (CSPs) oferecem ambientes de tempo de execução aos seus clientes. Dessa forma, os clientes podem se concentrar na manutenção de seu código de função, deixando o trabalho administrativo relacionado ao hardware, ao sistema operacional (SO) e, às vezes, ao tempo de execução para os CSPs. Os modelos comuns de plataforma sem servidor incluem função como serviço (FaaS) e contêiner como serviço (CaaS). Como as funções individuais são normalmente pequenas, mas cada aplicação dos clientes pode executar de uma a milhares de funções, os CSPs pretendem encaixar o máximo possível de funções em um único servidor para minimizar os tempos de inatividade e, por sua vez, maximizar o lucro. Uma abordagem bastante leve para servir ambientes de tempo de execução é executar contêineres, que encapsulam um processo com suas dependências, de modo que apenas os arquivos necessários para cada processo sejam carregados em sistemas de arquivos virtuais no topo de um kernel compartilhado. Isso reduz a alternância entre contêineres a pouco mais do que uma alternância de contexto entre processos. Por outro lado, a virtualização completa proporciona um bom isolamento entre máquinas virtuais (VMs) e, portanto, segurança entre locatários, embora seja bastante pesada, pois cada VM vem com seu próprio kernel.  Nenhuma dessas abordagens, contêiner ou VM, é ideal para uso em ambientes sem servidor, onde idealmente muitas funções de curta duração pertencentes a muitos usuários serão executadas simultaneamente e alternadas com frequência, portanto, novos mecanismos de isolamento foram desenvolvidos para esse caso de uso. Por exemplo, mecanismos para isolamento em processo [38, 45, 49] visam melhorar a segurança dos contêineres, reduzindo a superfície de ataque do tempo de execução e do kernel subjacente. Proteger o kernel é importante, pois um kernel comprometido leva diretamente a um sistema totalmente comprometido no caso do contêiner. No entanto, certas proteções poderosas, como a limitação de syscalls, também limitam a funcionalidade disponível para o contêiner e até quebram a compatibilidade com alguns aplicativos. Na pesquisa de VMs, os desenvolvedores criaram VMs cada vez menores e mais eficientes, levando eventualmente aos chamados microVMs. As MicroVMs fornecem as mesmas garantias de isolamento que as máquinas virtuais normais, mas são muito limitadas nas suas capacidades quando se trata de suporte a dispositivos ou sistemas operacionais, o que as torna mais leves em comparação com as VMs normais e, portanto, mais adequadas para computação sem servidor.  Firecracker [1] é um gerenciador de máquina virtual (VMM) projetado para executar microVMs enquanto fornece sobrecarga de memória e tempos de início comparáveis aos de sistemas de contêineres comuns. O Firecracker é desenvolvido ativamente pela Amazon Web Services (AWS) e tem sido usado na produção de serviços de computação sem servidor AWS Lambda [5] e AWS Fargate [4] desde 2018 [1]. O documento de design da AWS [1] descreve os recursos do Firecracker, como ele diverge das máquinas virtuais mais tradicionais e o modelo de isolamento pretendido que ele fornece: segurança para “múltiplas funções executadas no mesmo hardware, protegidas contra escalonamento de privilégios, informações divulgação, canais secretos e outros riscos” [1]. Além disso, a AWS fornece recomendações de configuração de host de produção [8] para proteger partes da CPU e do kernel com as quais uma VM Firecracker interage. Neste artigo, desafiamos a afirmação de que o Firecracker protege funções de canais secretos e secundários em microVMs. Mostramos que o Firecracker em si não adiciona contramedidas de ataque de microarquitetura, mas depende totalmente dos kernels Linux host e convidado e das atualizações de firmware/microcódigo da CPU.  Ataques de microarquitetura como as várias variantes Spectre [10, 13, 22, 30, 31, 33, 52] e amostragem de dados microarquiteturais (MDS) [14, 37, 46, 50] representam uma ameaça para sistemas multi-tenant, pois são frequentemente capaz de contornar os limites de isolamento de software e arquitetura, incluindo os de VMs. Spectre e MDS ameaçam locatários que compartilham recursos principais da CPU, como a unidade de previsão de ramificação (BPU) ou o buffer de preenchimento de linha (LFB). Os CSPs que fornecem serviços mais tradicionais podem mitigar o problema de recursos de hardware compartilhados fixando os locatários das VMs de longa duração em núcleos de CPU separados, o que efetivamente particiona os recursos entre os locatários e garante que o estado da microarquitetura seja afetado apenas por um único locatário por vez. .  Em ambientes sem servidor, entretanto, a ameaça de ataques microarquiteturais é maior. A razão para isto é a curta duração das funções executadas pelos diferentes inquilinos. Espera-se que os recursos do servidor em ambientes sem servidor sejam excessivamente comprometidos, o que leva a funções de locatário competindo por recursos de computação no mesmo hardware. Desabilitar o multithreading simultâneo (SMT), que desabilitaria o uso simultâneo de recursos da CPU por dois threads irmãos, reduz o poder de computação de uma CPU em até 30% [34]. Se os clientes alugarem núcleos de CPU específicos, essa penalidade de desempenho poderá ser aceitável ou ambos os threads de um núcleo de CPU poderão ser alugados juntos. Mas para serviços sem servidor, a penalidade de desempenho se traduz diretamente em 30% menos clientes que podem ser atendidos em um determinado período de tempo. É por isso que deve-se presumir que a maioria dos CSPs sem servidor mantém o SMT habilitado em seus sistemas, a menos que indiquem o contrário. A superfície de ataque microarquitetural é maior se o SMT estiver habilitado e o thread malicioso tiver acesso simultâneo a um núcleo compartilhado. Mas também existem variantes de ataque que funcionam tão bem se o thread do invasor preparar a microarquitetura antes de entregar o núcleo da CPU ao thread da vítima ou executar logo após o thread da vítima ter pausado a execução. E mesmo que o SMT seja desabilitado pelo CSP (como é o caso do AWS Lambda), os locatários ainda compartilham CPUs com vários outros dessa forma dividida em intervalos de tempo.  A AWS afirma que o Firecracker executado em um sistema com defesas de microarquitetura atualizadas fornecerá proteção suficiente contra ataques de microarquitetura [1]. A documentação do Firecracker também contém recomendações específicas para medidas de segurança microarquiteturais que devem ser habilitadas. Neste trabalho, examinamos as reivindicações e recomendações de segurança do Firecracker e revelamos descuidos em suas orientações, bem como ameaças totalmente não mitigadas.  Em resumo, nossas principais contribuições são:  • Fornecemos uma análise de segurança abrangente do isolamento entre locatários e locatários-hipervisor da computação sem servidor quando baseada na VM Firecracker.  • Testamos os recursos de defesa do Firecracker contra provas de conceito (PoCs) de ataques microarquiteturais, empregando proteções disponíveis por meio de atualizações de microcódigo e do kernel Linux. Mostramos que a própria máquina virtual fornece proteção insignificante contra as principais classes de ataques microarquiteturais.  • Identificamos uma variante do ataque Medusa MDS que pode ser explorada nas VMs do Firecracker, mesmo que não esteja presente no host. A mitigação do kernel que protege contra essa exploração e as variantes mais conhecidas do Medusa não é mencionada nas recomendações de configuração do host Firecracker da AWS. Além disso, mostramos que a desativação do SMT fornece proteção insuficiente contra a variante Medusa identificada, o que exige a mitigação do kernel.  • Identificamos variantes Spectre-PHT e Spectre-BTB que vazam dados mesmo com contramedidas recomendadas em vigor. As variantes Spectre-PHT continuam sendo um problema quando o SMT é desativado se o invasor e a vítima compartilharem um núcleo de CPU em intervalos de tempo.  1.1 Divulgação Responsável  Informamos a equipe de segurança da AWS sobre nossas descobertas e discutimos detalhes técnicos. A equipe de segurança da AWS afirma que os serviços da AWS não são afetados por nossas descobertas devido a medidas de segurança adicionais. A AWS concordou que o Firecracker não fornece segurança de microarquitetura por si só, mas apenas em combinação com atualizações de microcódigo e sistemas operacionais host e convidados seguros e planeja atualizar suas recomendações de configuração de host para instalações 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: resumo e introdução

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Modelo Bitcoin UTXO, alimentando um ecossistema único

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Guia do arquiteto para construir arquitetura de referência para um Datalake de IA/ML

Modelo Bitcoin UTXO, alimentando um ecossistema único

Navegando pelas águas: desenvolvendo aplicações RAG de nível de produção com data lakes

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps