Uma máquina virtual (VM) pode "hackear" outra VM em execução na mesma máquina física?

Questões:

• se uma VM estiver corrompida (hackeada), o que eu arrisco em outras VMs executadas na mesma máquina física?
• Que tipo de problemas de segurança existem entre as VMs em execução no mesmo host físico?
• Existe (você pode fazer) uma lista dessas (potenciais) fraquezas e / ou problemas?

Atenção:

Eu sei que existem muitos tipos / soluções de virtualização e podem ter diferentes pontos fracos. No entanto, estou procurando principalmente problemas gerais de segurança sobre as técnicas de virtualização, em vez de um bug específico do fornecedor.

Forneça fatos reais, estudos (sérios), problemas experientes ou explicações técnicas. Seja específico. Não (apenas) dê a sua opinião.

• Exemplos:

Há dois anos, ouvi dizer que poderia haver problemas de segurança relacionados ao MMU (acho que é o acesso à memória principal de outras máquinas), mas não sei se isso é uma ameaça prática até hoje, ou apenas uma pesquisa teórica. sujeito.

EDIT: Também encontrei esse ataque "Flush + Reload" capaz de recuperar chaves secretas do GnuPG na mesma máquina física, explorando o cache da CPU L3, mesmo se o GnuPG for executado em outra VM. O GnuPG foi corrigido desde então.

Obviamente, é possível explorar outra VM em execução no mesmo hardware, dada uma exploração em funcionamento. Além disso, um pode existir. Sua pergunta cita alguns trabalhos recentes que mostram um. Não compartilharei explorações específicas ou PoC aqui, mas vou dizer com prazer como elas podem ser feitas.

As explorações usadas neste contexto são naturalmente diferentes daquelas que funcionam quando você está executando na mesma máquina em que está tentando explorar um serviço e tendem a ser um pouco mais difíceis devido ao aumento do isolamento. No entanto, algumas abordagens gerais que podem ser usadas para realizar essa exploração incluem:

• Ataque o hypervisor . Se você puder obter um shell com privilégios suficientes no hipervisor com uma VM, poderá obter controle sobre qualquer VM no sistema. A maneira de abordar isso é procurar fluxos de dados que existem da VM para o hypervisor e são altamente dependentes do hypervisor; coisas como drivers paravirtualizados, compartilhamento da área de transferência, saída da tela e tráfego de rede tendem a criar esse tipo de canal. Por exemplo, uma chamada maliciosa para um dispositivo de rede paravirtualizado pode levar à execução arbitrária de código no contexto do hipervisor responsável por transmitir esse tráfego ao driver físico da NIC.
• Ataque o hardware no host . Muitos dispositivos permitem atualizações de firmware e, se for possível acessar o mecanismo para isso de uma VM, você pode carregar um novo firmware que favorece suas intenções. Por exemplo, se você tiver permissão para atualizar o firmware na NIC, poderá duplicar o tráfego vinculado a um endereço MAC (da vítima), mas com outro endereço MAC de destino (seu). Por esse motivo, muitos hipervisores filtram esses comandos sempre que possível; O ESXi filtra as atualizações de microcódigo da CPU quando se originam de uma VM.
• Ataque a arquitetura do host. O ataque que você citou, basicamente outro ataque de divulgação de chave com base no tempo, faz o seguinte: explora o impacto do mecanismo de cache no tempo da operação para discernir os dados que estão sendo usados ​​pela VM vítima em suas operações. No centro da virtualização está o compartilhamento de componentes; onde um componente é compartilhado, existe a possibilidade de um canal lateral. Na medida em que outra VM no mesmo host possa influenciar o comportamento do hardware durante a execução no contexto da VM vítima, a VM vítima é controlada pelo invasor. O ataque mencionado faz uso da capacidade da VM de controlar o comportamento do cache da CPU (estado universal essencialmente compartilhado) para que o tempo de acesso à memória da vítima revele com mais precisão os dados que está acessando; onde quer que exista estado global compartilhado, existe também a possibilidade de divulgação. Para entrar na hipótese de dar exemplos, imagine um ataque que massageie o VMFS do ESXi e faça com que partes de volumes virtuais façam referência aos mesmos endereços de disco físico, ou um ataque que faça um sistema de balão de memória acreditar que alguma memória pode ser compartilhada quando, de fato, deveria ser. private (isso é muito parecido com o modo como as explorações de uso após livre ou alocação dupla funcionam). Considere um hipotético CPU MSR (registro específico do modelo) que o hipervisor ignora, mas permite acesso; isso pode ser usado para passar dados entre VMs, quebrando o isolamento que o hipervisor deve fornecer. Considere também a possibilidade de a compactação ser usada para que componentes duplicados de discos virtuais sejam armazenados apenas uma vez - um canal lateral (muito difícil) pode existir em algumas configurações em que um invasor pode discernir o conteúdo de outros discos virtuais gravando e observando o que o hipervisor faz. É claro que um hipervisor deve se proteger disso e os exemplos hipotéticos seriam bugs críticos de segurança, mas às vezes essas coisas escapam.
• Ataque a outra VM diretamente . Se você tiver um host proximal para a VM vítima, poderá aproveitar o controle de acesso relaxado ou a comunicação intencional entre VMs, dependendo de como o host está configurado e de quais suposições são feitas ao implantar o controle de acesso. Isso é apenas um pouco relevante, mas merece menção.

Ataques específicos surgirão e serão corrigidos com o passar do tempo; portanto, nunca é válido classificar algum mecanismo específico como explorável, explorável apenas em condições de laboratório ou inexplorável. Como você pode ver, os ataques tendem a ser envolvidos e difíceis, mas quais são possíveis em um determinado momento é algo que muda rapidamente, e você precisa estar preparado.

Dito isto, os vetores que eu mencionei acima (com a possível exceção do último em alguns casos) simplesmente não existem em ambientes bare-metal. Então, sim, considerando que a segurança é proteger contra as explorações que você não faz conhece e que não estão na natureza, bem como as que foram divulgadas publicamente, você pode ganhar um pouco de segurança executando em bare metal ou em menos em um ambiente em que o hipervisor não hospeda VMs para todos.

Em geral, uma estratégia eficaz para a programação segura de aplicativos seria assumir que um computador possui outros processos em execução que podem ser controlados por invasores ou mal-intencionados e usar técnicas de programação com reconhecimento de exploração, mesmo que você ache que não está garantindo esse processo. existe na sua VM. No entanto, principalmente nas duas primeiras categorias, lembre-se de que quem toca o hardware vence primeiro.

Em teoria, não. O objetivo principal do hypervisor é isolar máquinas virtuais umas das outras.

Na prática, houve (e pode haver no futuro) erros de segurança em vários hipervisores, o que pode permitir que uma máquina virtual afete o hipervisor ou outras máquinas virtuais no mesmo host. Medidas de segurança como sVirt (para KVM / QEMU) destinam-se a resolver esse problema.

Edit: Eu pensei que este tópico foi feito há meses, mas acabou de ser revivido e agora a OP está pedindo mais 'fatos reais, estudos citados' etc. etc., então imaginei o que diabos.

Explorações dessa natureza são:

1. Raro
2. De natureza sensível e, portanto, não compartilhadas abertamente, e quando forem, as explorações serão corrigidas pelo fornecedor antes que alguém neste site tenha conhecimento delas.
3. Complicado e variará de acordo com o fornecedor

Não podemos dizer que é impossível invadir um hypervisor e obter acesso a outras VMs. Também não podemos quantificar quanto risco existe, exceto por essa experiência nos mostrar que é bastante baixa, considerando que você não encontrará muitas histórias de ataques que utilizaram explorações de hipervisor.

Aqui está um artigo interessante, ao contrário, que sugere que mais de alguns ataques baseados em hipervisores foram realizados.

No entanto, com a tecnologia dependente dos hipervisores agora mais do que nunca, essas explorações seriam corrigidas e protegidas com mais urgência do que quase qualquer outro tipo de exploração.

Aqui está um trecho do Relatório de tendências e riscos semestrais do IBM X-Force 2010:

(Por favor, abra esta imagem em uma nova guia para visualizá-la em tamanho real.)

Observe a porcentagem medida de vulnerabilidades "Escape to hypervisor", que me parece bastante assustadora. Naturalmente, você gostaria de ler o restante do relatório, pois há muito mais dados para fazer backup das reivindicações.

Aqui está uma história sobre uma possível exploração realizada no hipervisor do Playstation 3, o que é divertido. Talvez não seja tão impactante para os seus negócios, a menos que seja da Sony; nesse caso, é extremamente impactante.

Aqui está um artigo maravilhoso de Eric Horschman, da VMware, no qual ele meio que me soa como um adolescente enlouquecendo com anti-Micro $, mas ainda é um bom artigo. Neste artigo, você encontrará petiscos como este:

Os moradores da casa de vidro da Microsoft tinham outras pedras para atirar em nosso caminho. A Microsoft apontou o CVE-2009-1244 como um exemplo de vulnerabilidade de invasão de convidado no ESX e ESXi. Uma exploração de convidado é um negócio sério, mas, mais uma vez, a Microsoft está deturpando os fatos. A VMware respondeu rapidamente para corrigir essa vulnerabilidade em nossos produtos, e o ESX foi muito menos afetado do que a Microsoft levaria você a acreditar:

Quibbling entre concorrentes. Mas provavelmente a coisa mais lúcida que ele diz em todo o artigo é esta:

A verdade é que vulnerabilidades e explorações nunca desaparecerão completamente para nenhum software corporativo.

O sempre cotável Theo de Raddt do projeto OpenBSD:

Você é absolutamente iludido, se não estúpido, se pensa que uma coleção mundial de engenheiros de software que não pode escrever sistemas operacionais ou aplicativos sem falhas de segurança, pode se virar e escrever subitamente camadas de virtualização sem falhas de segurança.

Um pouco inflamatório, mas seu argumento é bem aceito. Em teoria, a virtualização deve fornecer isolamento completo entre as máquinas virtuais e seu host. Na prática, existem vulnerabilidades de segurança ocasionais que permitem que invasores avançados circunavegam essas proteções e obtenham acesso a outras máquinas virtuais ou, pior ainda, a seus hosts (consulte Um estudo empírico sobre a exposição de segurança a hosts de ambientes virtualizados hostis ). Como Ryan Ries menciona, esses tipos de vulnerabilidades são bastante raras (o que não significa que não estejam lá) e geralmente não são divulgadas pelos fornecedores, mas existem.

Se você estiver preocupado com o potencial para esses tipos de ataques (e acho que você deveria estar), recomendo que você não misture zonas de segurança em um único host virtual ou cluster de host virtual. Por exemplo - você teria um cluster de host virtual de dois hosts dedicado para máquinas virtuais DMZ, um cluster dedicado para middleware e um cluster dedicado para ativos protegidos. Dessa forma, no caso de uma vulnerabilidade ser explorada de forma a permitir que um invasor subverta outras máquinas virtuais ou, pior ainda, o hipervisor, seu modelo de segurança ainda está intacto.