Different Variants: Meltdown and Spectre
This article discusses only Meltdown and its affect on hypervisor environments since it is the easiest to implement. Note that Spectre is capable leaking hypervisor memory from all hypervisors running on affected processors (Intel and possibly AMD, ARM) but it is both more difficult to exploit and to mitigate. Please read on to understand how Meltdown affects your virtualization stack:
How Meltdown Affects Virtualized Environments
Every hosting provider held their breath over the past week wondering if the as-of-yet undisclosed Intel hardware bug now released as “Meltdown” would affect their visualization stack. They all want to know: is this a hypervisor escalation!? Here in this post we use the word “affected” meaning guest-to-hypervisor memory read access.
The Meltdown bug enables reading memory from address space represented by the same pagetable—anyone using virtual page tables is unaffected between virtual tables. That is, Guest-to-Host pagetables are unaffected, only Guest-to-Guest or Host-to-Host, and of course Host-to-Guest since the host can already access the guest pages.
For a hosting provider this means different customer VMs on the same fully-virtualized hypervisor cannot access each others’ data—but—different users on the same guest instance can access each others’ data. This latter part holds true for non-virtualized hardware as well: users under the same OS kernel can access each others’ data. Thus, containers are affected!
Which Technologies Are Affected?
Fully virtualized technologies are not affected in the sense that guests cannot access host (hypervisor) memory. However, an unprivileged guest process can still access privileged (and other unprivileged) guest process memory pages. Container-based technologies are affected by Meltdown across container boundaries.
Affected Virtualization Technologies
Anything container based: neighbor containers can read other neighbor containers process memory.
- Docker
- LXC
- OpenVZ
- UML
- Paravirtual Xen
- Chroot Jails
Unaffected Virtualization Technologies
Any fully virtualized technology is unaffected.
- KVM
- Xen HVM
- HyperV
- VirtualBox (if using VT)
Solutions
- Update your distribution kernel if your OS distribution has released an update for CVE-2017-5715, CVE-2017-5753, and CVE-2017-5754. See this post for updated distribution kernel versions that address these CVEs: https://www.linuxglobal.com/spectre-meltdown-security-updates-distribution/
- If you cannot do #1, your best option is to install Linux 4.15-rc6 or one of the supported vanilla kernel patches in the link above. On all systems. Yes, 4.15-rc6 is a release candidate, but this kernel is receiving wide spread testing because of this bug.
- If this is not an option and you mostly trust the code running inside of the container, then you could run your container instances under KVM to isolate them from eachother to protect your guests and privileged container.
- If running Xen-PV, switch everything to Xen-HVM and hope for the best. Many operating systems will boot in either environment unless your guest kernel was built specific to Xen PV—but there could be driver issues between the two.
- If you do not trust your users on a single host, then your best option is #1 above.
Remember, the only real fix is to install an updated kernel on all servers, physical or virtual. Solutions 3and 4 only mitigate the problem since the guest is still vulnerable to interprocess memory reads.
Help!
We can help! Just give us a call or send an email so we can make a plan and get you running secure, once again!
-Eric
Hi, so does it mean that for KVM, I dont need to patch guest OSes?
For Meltdown, the guest OS doesn’t need to be patched to protect the hypervisor—however—the guest OS needs to be patched to protect the guest OS. For Spectre, you will need a microcode update for your CPU as well as software patches.
I am confused between these two phrases:
(1) “That is, Guest-to-Host pagetables are unaffected, only Guest-to-Guest or Host-to-Host, and of course Host-to-Guest” and (2) “different customer VMs on the same fully-virtualized hypervisor cannot access each other’s data”
(1) claims Guest-to-Guest scenario to be affected, but (2) claims they aren’t. Am I missing something here?
Customer VMs on the same hypervisor would fall under the “Guest-to-Guest” category. However, note that in the first paragraph of this article it is discussing Meltdown and exploits have since come out that are variations on cache timing attacks which can expose hypervisor memory to guests. Be sure you are up to date with your firmware and Linux kernel, and then check `tail /sys/devices/system/cpu/vulnerabilities/*` to see if you have any unmitigated processor vulnerabilities. If you would like to schedule a call, then we can talk about this in more detail. -Eric