Starting from 3/4.01.2018 and for some end of the last year was lots of people in IT are extremely busy. All because of intel (and not only) CPU vulnerabilities.
There is much information on the Internet. Extremely much. And that’s good. But at the same time, some information can make confusion cause are not actually or are contradictory.
This page is an attempt to organize this chaos, or at last, ask few questions on issues that are unclear to me.
In general, vulnerabilities were discovered independently by two teams. One academic team from the Graz University of Technology in Austria(https://gruss.cc/files/kaiser.pdf) and the other from Google Zeroday program (https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html).
It is not for the first time when bugs are discovered parallel at the same time (like the five different engineers independently invented the TV in 1920) but it is the thing always fascinated me (https://www.wired.com/story/meltdown-spectre-bug-collision-intel-chip-flaw-discovery/).
Anyway, the problem is huge because it touches many of manufacturers (intel, AMD, ARM) but also it is not easy to fix it.
At this moment we have 3 CVE articles (and three describing the problem:
- CVE-2017-5715 (Spectre, Branch target injection) — requires the system ROM, OS and hypervisor to be upgraded –> this seems to be the bug the hardest to solve.
- CVE-2017-5753 (Spectre, Bounds check bypass) — requires updates from operating system vendor
- CVE-2017-5754 (Meltdown, Rogue data cache load) — requires only updates of a vendor-supplied operating system (ESXi not affected by this vulnerability)
Usually security problem needed to be patched and it is fairly simple. We need to feet to requirements of patch, this means fulfill some dependency – patch something before the accurate patch.
With Spectre is slightly different. All hardware/software stack need to be patched. This means we need to patch BIOS (with microcodes), hypervision (ESXi) – with bugfix and also microsodes, virtual hardware need to in proper version, VMs need to be patched and at the end (or rather at the beginning if we talk about the order) vCenter need to patched.
So summarizing, you have to patch everything (literally everything, maybe besides vmtools – but I do not see any reason to not do this).
BUT (status at the end of January) the problem is that you CAN’T. At last you can’t patch for all threats because there is no actual patches. There WAS, but due to numerous hosts restart intel roll them back. Going further almost every vendor I know also had to move back their patches and new releases.
Just please take a look at article: https://kb.vmware.com/s/article/52085 where you can find a lot of crossed out sentences.
So, the status is that all saying: patch to the latest available fix but even so you won’t be safe (at last for CVE-2017-5715). Everyone looks at intel, and intel give no date when is going to release microcode.
Following the article https://kb.vmware.com/s/article/52245, VMware split the mitigations fall into 3 categories:
- Hypervisor-Specific Mitigation
- Hypervisor-Assisted Guest Mitigation
- Operating System-Specific Mitigation
Soruce:
- https://meltdownattack.com/
- https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html; VMware Security Advisories; VMSA-2018-0002.2
- https://kb.vmware.com/s/article/52345; Intel Sightings in ESXi Bundled Microcode Patches for VMSA-2018-0004 (52345); kb52345 — information, which processors restart after the last patch
- https://kb.vmware.com/s/article/52264; VMware Virtual Appliances and CVE-2017-5753, CVE-2017-5715 (Spectre), CVE-2017-5754 (Meltdown) (52264); kb52264
- https://kb.vmware.com/s/article/52085; Hypervisor-Assisted Guest Mitigation for branch target injection (52085); kb52085; upgrade steps
- https://kb.vmware.com/s/article/52245; VMware Response to Speculative Execution security issues, CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown) (52245); kb52245
No Comments