É possível que uma máquina virtual como o VirtualBox tenha o “espectro” de vulnerabilidade de segurança? Acho que a VM talvez execute uma execução fora de ordem, mas na minha opinião não é possível espiar o cache para ler o resultado.
Existe alguma explicação de como é possível ler o cache de uma CPU virtual?
Responder1
Sim, o Spectre pode cruzar os limites de host/convidado, convidado/host e convidado/convidado porque esta é uma falha no nível da CPU que significa que informações potencialmente confidenciais podem vazar em qualquer coisa que seja executada em um núcleo da CPU.
A maioria das notícias na Internet fala sobre os provedores de nuvem serem os mais atingidos por isso, pois possuem enormes clusters de sistemas que são virtualizados e podem ser potencialmente usados de forma abusiva para vazar informações confidenciais.
A maioria dos grandes provedores já deveria ter corrigido as falhas, da melhor maneira possível, mas esse será um problema que permanecerá conosco por algum tempo.
Security.SE tem umperguntas e respostas canônicassobre isso e menciona VMs:
Estou executando uma máquina virtual/contêineres. Até que ponto estou vulnerável?
ConformeResposta de Steffen Ullrich
- Os ataques Meltdown não atravessam VMs, apenas vazam memória do kernel para processos locais.
- O Spectre pode funcionar em VMs.
Também, deSteffen novamente, Meltdown e Spectre funcionam com contêineres, pois os contêineres dependem do kernel do host.
As VMs usam a CPU real do seu sistema com algumas instruções privilegiadas capturadas e capazes de serem redirecionadas. Ele usa os mesmos caches e instruções que o host. É essencialmente apenas mais uma camada dentro da CPU física do seu sistema.
A virtualização só é rápida porque usa a CPU física com o mínimo de abstração possível e depende do hardware da CPU para fornecer isolamento. Coisas como qemu podem fazeremulaçãoo que seria mais seguro, pois não é uma CPU de hardware, mas émuitomais lento e é diferente da virtualização.
DePostagem canônica do Security.sede novo:
O Spectre funciona em um nível diferente e não permite acesso aos dados do espaço do kernel a partir do espaço do usuário. Neste ataque, o invasor engana a execução especulativa para executar instruções erroneamente de forma preditiva. Resumindo, o preditor é coagido a prever um resultado de ramificação específico (se -> verdadeiro), que resulta na solicitação de um acesso à memória fora do limite que o processo vítima normalmente não teria solicitado, resultando em uma execução especulativa incorreta. Então, pelo canal lateral, recupera o valor desta memória. Dessa forma, a memória pertencente ao processo vítima é vazada para o processo malicioso.
Então, porque a VM é executada em hardware de CPU real e tudo o que ela precisa fazer é executar um loop específico para "treinar" o mecanismo de execução especulativo. Em seguida, ele pode usar o tempo preciso para observar os caches em busca de padrões específicos de acesso indicativos do processo host ou convidado (ou outra VM) que ele está procurando explorar.
Desta forma, significa que uma máquina pode ser explorada em todas as direções. De host para VM, de VM para host e de VM para VM.
Sim, não é nada fácil e é difícil de realizar, pois o núcleo da CPU da VM pode mudar conforme o capricho do host e o host também pode agendar tarefas em núcleos diferentes, mas durante um longo período de tempo, informações suficientes poderia ser vazado para fornecer uma chave secreta para algum sistema ou conta importante. Com tempo suficiente e algum software furtivo adequado, tudo estará potencialmente aberto.
Se você deseja uma VM "segura", precisa garantir que seus núcleos estejam isolados. A única maneira real de bloquear esse ataque seria "forçar" o host e as VMs a usarem apenas determinados núcleos, para que nunca funcionem no mesmo hardware, mas isso levaria a um aumento efetivo no custo, pois você não seria capaz de ter tantas VMs em um determinado host. Você nunca seria capaz de executar mais VMs do que os núcleos disponíveis, o que é algo que eu esperaria que fosse feito em servidores de "baixa carga", já que muitos sistemas ficam ociosos por 90% de sua vida útil.
Responder2
O simulador gem5 simula a microarquitetura da CPU e pode ser usado para estudar o Spectre
Se você estiver interessado em estudar/reproduzir vulnerabilidades puramente com emulação, sem usar a CPU host, não acho que o QEMU seja detalhado o suficiente para observá-las, pois não simula o pipeline da CPU.
gema5no entanto, é usado para estimar o desempenho do sistema em pesquisa e desenvolvimento e simula componentes internos da CPU suficientes para você observar o Spectre em um ambiente totalmente limpo e controlado.
Uma demonstração legal do x86_64 com visualização foi publicada em:http://www.lowepower.com/jason/visualizing-spectre-with-gem5.html
A desvantagem do gem5 é que ele é muito mais lento que o QEMU e a simulação é mais detalhada.