Meltdown & Spectre - O patch do kernel convidado de um hipervisor não corrigido evita vazamentos de memória entre VMs?

Question

24 horas após o lançamento em larga escala das vulnerabilidades, a Rackspace está silenciosa sobre o Specter e o Meltdown. Eles não têm um plano para consertar todos os hipervisores Xen. Todos os seus servidores de plataforma mais recentes são servidores HVM, que são vulneráveis. Os servidores PV mais antigos não são vulneráveis.

Atualizei o kernel do Linux dos meus convidados do HVM, mas a Rackspace não atualizou nenhum dos hipervisores. A atualização do kernel convidado em um hypervisor não corrigido evitará que VMs "malvadas" acessem a memória que vazou do meu host corrigido?

    

Answer 1

Pelo que eu entendi das vulnerabilidades, não - os ataques de cache especulativo ignoram todas as proteções da CPU contra um processo que captura memória de qualquer endereço arbitrário.

Acredito que isso incluiria as VMs vizinhas (mesmo as remendadas para se proteger contra o ataque), bem como o espaço de memória do kernel do hipervisor - mas mesmo que haja algo que esteja faltando que proteja contra a divulgação direta da memória, Também há potencial de que o invasor possa usar seu acesso à memória do kernel para obter acesso mais completo ao hipervisor.

Você definitivamente não quer correr o risco de executar uma carga de trabalho sensível em um hipervisor não corrigido de qualquer tipo se não confiar em todas as VMs em execução nele.

    

Answer 2

Espectro e Meltdown.

Por onde começamos? um mau, quero dizer muito mau comunicado de imprensa de algo que pode ou não afetar seu computador, estação de trabalho, servidor ou servidor na nuvem. Sim é totalmente, mas você tem que ter acesso local à CPU associada, que pode ser um PC ou um telefone, parece, a Apple foi feita um exemplo, mas vamos pensar sua CPU ARM, de modo que cada plataforma móvel que suporta o (recurso / exposição do microcódigo / muito controle sobre a CPU do sistema operacional / etc / etc)

O aplicativo tem que estar rodando na CPU do dispositivo, então eu acho que o acesso ao console, ou pelo menos o usuário remoto que acessa o sistema, acessa o dispositivo de entrada ....

Neste momento, a única maneira conhecida de explorar essas vulnerabilidades é local / acessar diretamente a CPU (Novamente, pode ser remoto, uma vez que você tem SSH / VNC, etc)

Abaixo estão os patches que encontrei até agora.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

link l

Agora, essa é a melhor resposta para o problema em questão

O que nossos amigos BSD disseram?

Google errado; (

uma verificação do Powershell para o mesmo;)

O kernel do Linux Ok, tivemos uma semana interessante, e agora todos sabem por que estávamos mesclando todos esses patches de isolamento de tabela de página x86 ímpar sem seguindo todas as regras normais de tempo de lançamento.

Eu posso / vou voltar e editar esta postagem. Eu tenho certeza que o não-problema (até em estado selvagem) não vai ser um problema real longo tern. O Google deveria realmente ter seguido as datas de lançamento da divulgação aqui! -1 para o Google