68

The patch for Meltdown is rumoured to incur a 30% performance penalty, which would be nice to avoid if possible. So this becomes a Security vs Performance risk-assessment problem.

I am looking for a rule-of-thumb for assessing the risk of not patching a server or hypervisor.

From reading the whitepapers, my understanding is that you definitely need to apply the patch if your machine:

  • is a workstation that runs random potentially malicious code - including, it turns out, java script from random websites,
  • is a VM that could potentially run malicious code (which essentially becomes the first case).
  • is a hypervisor that runs untrusted VMs next to sensitive VMs (which essentially becomes the first case),

My understanding is that the risk is (significantly) lower in the following cases:

  • server running on dedicated hardware running a tightly-controlled set of processes in a tightly-controlled network (including not using a web browser to visit untrusted sites)
  • VM running a tightly-controlled set of processes on a virtualization stack of other tightly-controlled VMs, all in a tightly-controlled network.

Is that logic sound, or am I missing something?

UPDATE: early adopters of the patch in Azure are reporting no noticeable slowdown, so this may all be moot.

Related question: What are the risks of not patching a workstation OS for Meltdown?

Mike Ounsworth
  • 58,107
  • 21
  • 154
  • 209
  • 11
    Rumor has it the performance implications aren't that bad, [particularly for newer processors with PCID](https://en.wikipedia.org/wiki/Kernel_page-table_isolation#Implementation). – Alexander O'Mara Jan 04 '18 at 06:06
  • Where in the whitepaper did you find information about the vulnerability of a VM (assuming a patched hypervisor)? – JoshHetland Jan 04 '18 at 06:46
  • @JoshHetland The question postulates an *unpatched* hypervisor. – Philip Kendall Jan 04 '18 at 06:47
  • 1
    @AlexanderO'Mara "a Linux developer measured it to be roughly 5% for most workloads and up to 30% in some cases, **even with the PCID optimization**" – ave Jan 04 '18 at 16:23
  • 7
    "is rumoured to incur a 30% performance penalty" - When I first heard of this, people were saying "likely 5-30%" penalty. The estimated worst possible performance hit seems to have rapidly started to be treated as the likely performance hit... – Izkata Jan 04 '18 at 21:02
  • 2
    @Ave Most practical desktop workloads are [looking at 1-2%](https://www.techspot.com/article/1554-meltdown-flaw-cpu-performance-windows/), if even that much. [Synthetic I/O benchmarks](https://www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1) are hardest hit (at >20%), and some server workloads (especially DB servers?) will suffer at 10-15%. So if performance is a consideration, you're probably better off actually testing your real workload (and using the config options available in both Linux and Windows to toggle PTI) rather than going off publicly reported numbers. – Bob Jan 05 '18 at 01:45
  • 3
    I also want to stress the part mentioned by @Izkata : 30% is mentioned as a worst-case scenario (though even 5% is high for enterprise environments). We'll know A LOT more on January 9th when the embargo on many parts of this subject will be lifted and the patch from Microsoft arrives. – Radu Murzea Jan 05 '18 at 10:02

2 Answers2

35

Basically, if you run code from untrusted sources on a machine that has data you don't want that code to have access to, you need to patch. Desktop computers should be patched because they've got an unfortunate habit of encountering untrusted code; shared-hosting servers, particularly virtual private server hosts, must be patched, because Meltdown lets one user access every other user's data.

Note that the Meltdown attack cannot be used to break out of a virtual machine. You can break out of a container, sandbox, or a paravirtualized system, but performing the Meltdown attack in a fully-virtualized system just gets you access to that VM's kernel memory, not the host's kernel memory.

Mark
  • 34,513
  • 9
  • 86
  • 135
  • 16
    I respectfully disagree, from [VMWare's security bulletin](https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html): _"Result of exploitation may allow for information disclosure from one Virtual Machine to another Virtual Machine that is running on the same host"_. The whitepaper only mentions breaking out of containers, but I suspect the exploit can be applied more broadly. – Mike Ounsworth Jan 04 '18 at 16:33
  • 2
    @MikeOunsworth (and Mark), the VM piece of this question should be addressed in [a separate question](https://security.stackexchange.com/q/176709/149193). – NH. Jan 04 '18 at 19:21
  • Despite the excellent other Q&A pair, this answer and the above comment should be updated to reflect the content of that post - is it the answer or comment here which is incorrect? – Tim Jan 05 '18 at 00:06
  • 9
    @Tim, the comment is based on a misreading of the security advisory. Spectre can break out of a virtual machine, Meltdown can't. – Mark Jan 05 '18 at 01:03
  • To re-iterated: the VMWare bulletin is discussing Spectre, aka CVE-2017-5753 and CVE-2017-5715. This answer is discussing Meltdown, aka CVE-2017-5754. – Mark Jan 05 '18 at 19:06
11

My understanding of the issue is that it is a local information leak, where local means that the information are leaked "only" to processes on the same physical hardware and not (directly) to remote systems. And, it is an attack which was shown to be actually usable in practice to extract sensitive information, even it is currently not trivially to exploit. But how easy the exploit is might quickly change as seen by Rowhammer, which evolved within a short time from only being a mostly theoretical problem to more reliable exploiting the issue using Javascript inside a browser or to root Android phones.

Thus, if there is the chance that some untrusted code is executed on the server you should patch. That's why all the larger cloud providers already patched their systems or will do shortly. And that's why the patches were so quickly incorporated into the Linux kernel, which is very unusual for changes to the memory subsystem.

Note that untrusted code might not only be run if you have untrusted users on the system. It can also happen if you process data originating from an untrusted source. For example an attacker could use existing functionality of your web server to upload an image which then gets converted on your server (i.e. scaling or similar). Given the history of bugs in graphic libraries it would not be unlikely that this conversation could result in code execution. And giving the nature of the issue I doubt that sandboxes, docker or similar will stop exploitation of the bug.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 4
    The severity is *half* the reason the patches were incorporated into Linux so quickly. The other half is that the patches were already under development, as an extension to the KASLR protection mechanism. – Mark Jan 04 '18 at 08:59
  • [citation needed] but I believe Spectre is rumored to work with JavaScript code running in the browser sandbox? I can't remember exactly where I got that from but I _think_ a friend said he read it in the whitepaper. – strugee Jan 04 '18 at 09:08
  • 9
    @strugee: yes, citation is very much needed. But anyway: running Javascript inside the browser definitely counts in most cases as running code from an untrusted source. – Steffen Ullrich Jan 04 '18 at 09:13
  • 9
    @SteffenUllrich @strugee source is in the [whitepaper](https://spectreattack.com/spectre.pdf), page 6 `Example Implementation in JavaScript`. Quote: `JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs` – Steffen Winkler Jan 04 '18 at 14:01
  • @SteffenWinkler am I safe if I use Firefox? – John Dvorak Jan 04 '18 at 23:14
  • 1
    @JohnDvorak: Only if Firefox doesn't JIT its JavaScript. – Joshua Jan 04 '18 at 23:36
  • Oh golly. Everything more modern than IE is screwed, then. – John Dvorak Jan 04 '18 at 23:38
  • @JohnDvorak On the contrary, everything more modern than IE is getting patches that mitigate this vuln. https://www.chromium.org/Home/chromium-security/ssca https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blogs.windows.com/msedgedev/2018/01/03/speculative-execution-mitigations-microsoft-edge-internet-explorer/ – Bob Jan 05 '18 at 01:35
  • Oh, nice! ..... – John Dvorak Jan 05 '18 at 01:37
  • 2
    @JohnDvorak Firefox 57.0.4 - that was launched just yesterday (Jan 4, 2018) - included "fixes" (mitigation measures) for Meltdown and Spectre attacks, according to: [1] https://www.mozilla.org/en-US/firefox/57.0.4/releasenotes/ ; [2] https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ and [3] https://www.mozilla.org/en-US/security/advisories/mfsa2018-01/ – ricmarques Jan 05 '18 at 10:58