Sim, o Specter pode cruzar os limites host / guest, guest / host e guest / guest porque essa é uma falha no nível da CPU que significa que informações potencialmente confidenciais podem vazar em qualquer coisa que seja executada no núcleo da CPU.
A maioria das notícias na internet fala sobre os provedores de nuvem serem os mais prejudicados, já que eles têm enormes conjuntos de sistemas que são virtualizados e poderiam ser potencialmente usados para vazar informações confidenciais.
A maioria dos grandes provedores deveria ter sido corrigida contra as falhas até agora, da melhor maneira possível, mas isso vai ser um problema que vive conosco por algum tempo.
O Security.SE tem um Perguntas e Respostas canônicas Q & Um sobre isso e menciona VM's:
I am running a Virtual Machine/Containers, to what extent am I vulnerable?
As per Steffen Ullrich's answer
- Meltdown attacks do not cross VMs, only leaks kernel memory to local processes.
- Spectre can work across VMs.
Also, from Steffen again, Meltdown and Spectre works with containers, as containers relies on the host kernel.
As VMs usam a CPU real em seu sistema com algumas instruções privilegiadas bloqueadas e capazes de serem redirecionadas. Ele usa os mesmos caches e instruções que o host. É essencialmente apenas outra camada dentro da CPU física em seu sistema.
A virtualização é rápida apenas 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 o qemu podem fazer emulação , o que seria mais seguro, pois não é uma CPU de hardware, mas é muito mais lento e diferente da virtualização.
A partir da postagem canônica do Security.se novamente:
Spectre works on a different level and does not allow access to kernel-space data from user-space. In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.
Portanto, como a VM é executada no hardware real da CPU e tudo o que ela precisa fazer é executar um loop específico para "treinar" o mecanismo de execução especulativa. Em seguida, ele pode usar o tempo preciso para observar os caches para determinados padrões de acesso indicativos do processo de host ou convidado (ou outra VM) que está procurando explorar.
Desta forma, significa que uma máquina é explorável em todas as direções. Do host à VM, da VM ao host e da VM à VM.
Sim, não é fácil e é uma tarefa difícil, já que o núcleo da CPU da VM pode mudar por capricho do host e o host pode agendar tarefas em diferentes núcleos, mas por um longo período tempo suficiente informação poderia ser vazada para desistir de uma chave secreta para algum sistema importante ou conta. Com tempo suficiente e algum software adequadamente sigiloso, tudo está potencialmente aberto.
Se você quer uma VM "segura", então você tem que garantir que seus núcleos estão isolados. As únicas maneiras reais de bloquear esse ataque seria "forçar" o host e as VMs a usar apenas determinados núcleos para que nunca sejam executados no mesmo hardware, mas isso levaria a um aumento efetivo no custo, já que você não conseguiria tem tantas VMs em um determinado host. Você nunca seria capaz de executar mais VMs do que seus núcleos disponíveis, o que é algo que eu esperaria que fosse feito em servidores de "carga baixa", já que muitos sistemas ficam ociosos por 90% de sua vida útil.