12

24 hours after the wide scale release of the vulnerabilities, Rackspace is silent about Spectre and Meltdown. They do not have a plan for patching all of their Xen hypervisors. All their newer platform servers are HVM servers, which are vulnerable. Older PV servers are not vulnerable.

I have updated the Linux kernel of my HVM guests, but Rackspace has not updated any of their hypervisors. Will updating the guest kernel on an unpatched hypervisor prevent "bad guy" VMs from accessing memory leaked from my patched host?

chicks
  • 3,639
  • 10
  • 26
  • 36
Danny F
  • 488
  • 3
  • 10

2 Answers2

12

From what I understand of the vulnerabilities, no - the speculative caching attacks bypass all of the CPU's protections against a process grabbing memory from whatever arbitrary address.

I believe this would include the neighbor VMs (even those patched to protect against the attack themselves) as well as the hypervisor's kernel memory space - but even if there is something that I'm missing that would protect against direct memory disclosure, there's also potential that the attacker could use their access to kernel memory to gain more complete access to the hypervisor.

You definitely don't want to risk running a sensitive workload on an unpatched hypervisor of any kind if you don't trust all of the VMs running on it.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • 6
    To put it plainly: Having a patched guest kernel may prevent _your_ VM from accessing the hypervisor or other VMs, but it won't prevent other VMs from accessing yours! – Michael Hampton Jan 05 '18 at 00:14
  • Hi Shane, that's my belief as well. Do you have any documentation to back that up? The point specifically about the memory of a patched guest being vulnerable to other guests on the same hardware. Thanks. – Danny F Jan 05 '18 at 00:50
  • 2
    @DannyF The most direct reference to this that I could find was in the [meltdown paper](https://meltdownattack.com/meltdown.pdf)- "physical memory of other processes, the kernel, and in case of kernel-sharing sandbox solutions (e.g., Docker, LXC) or Xen in paravirtualization mode, memory of the kernel (or hypervisor), **and other co-located instances**" – Shane Madden Jan 05 '18 at 01:58
-4

Spectre and Meltdown.

Where do we start? a bad, I mean very bad press release of something that may or may not affect your computer, workstation, server or server in cloud. Yes it totally is but you have to have local access to the CPU associated, that may be a PC or a Phone it seems, Apple has been made an example but lets think its ARM CPU, so thats every Mobile platform that supports the (feature/microcode exposure/too much control over the CPU from the OS/etc/etc)

The Application has to be running on the CPU of the device so I would think console access, or at least remote user who accesses the system, input device access....

At this time, the only known way to exploit these vulnerabilities is from local/directly access the CPU(Again can be remote once you have SSH/VNC etc)

Below are the patches I have found so far. 

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

https://alas.aws.amazon.com/ALAS-2018-939.html

Now this has to be the best response to the issue at hand right now

What did our BSD friends say?

Bad google ;(

a Powershell check for the same ;)

The Linux Kernel Ok, we had an interesting week, and by now everybody knows why we were merging all those odd x86 page table isolation patches without following all of the normal release timing rules.

I may/will come back and edit this post. I am sure the non-issue (until in the wild) wont be a real problem long tern. Google should really have followed disclosure release dates here! -1 for Google

Andrew Smalley
  • 11
  • 4
  • "Amazon Linux (AMI)" is Amazon's Linux distro, which is affected in the same way as all other guest operating systems. More relevant in this context is https://aws.amazon.com/de/security/security-bulletins/AWS-2018-013/ (initial section) for the EC2 announcement (their virtualization platform), as you seemed to be trying to list virtualization solutions. – Håkan Lindqvist Jan 08 '18 at 21:29
  • 1
    Reading and re-reading this, I don't believe it actually addresses the question? It's mostly just a rant about the disclosure process? – Håkan Lindqvist Jan 08 '18 at 21:58
  • I appreciate the editorial, and links for fixes, but this answer is misleading or at least confusing. I believe it indicates that the scenario I described would require local access to the xenserver hypervisor, which isn't true. The only requirement is the bad guy having their own VM on the same hypervisor as the victim VM. – Danny F Jan 09 '18 at 00:21