Spectre and Meltdown: What you need to know

In the first days of 2018, a number of vulnerabilities were disclosed that are present in many modern-day CPUs.

In this blog post we address the most frequently asked questions about Spectre and Meltdown with a focus on providing you with actionable guidance about what to do. This post is in addition to our webinar

Should you wonder what Spectre and Meltdown are, a great, non-technical description has been written by Bert Hubert [1].

What is the real-world impact of these vulnerabilities?

Spectre and Meltdown have been called the 'worst ever' bugs in the media [1] and while definitely serious, this is certainly overstated.

Meltdown is relatively simple to exploit and we are already seeing concept attacks using Javascript in a browser, which is a very easy attack vector. It is likely that there will be commodity attacks out there for Meltdown in the near future. Fortunately, Meltdown can be mitigated with operating system (OS) patches (where available).

These OS patches do not protect against the browser attack vector. Even if the kernel page tables are isolated, a browser attack could still leak browser userland memory (as shown in the demo in the webinar). Site isolation and browser updates will mitigate this browser vulnerability.

Spectre is more difficult to exploit in general in the context of a real attack, but keep in mind that browser exploits target the variant 1 of Spectre. Although more difficult to mitigate, as it requires CPU changes and changes to software, we don't expect pure Spectre-type attacks to be commoditized and used.

In short, in our view Meltdown is more worrisome than Spectre but can be easily mitigated.

Will attackers abuse these vulnerabilities?

These are the types of information an attacker might try to leak:

Sensitive information. This could be anything, from passwords to credit card numbers to snippets of text.
Secrets within memory. These could be used in follow-on attacks or for privilege escalation. The most useful here could be passwords or private keys stored in memory, which could be used for privilege escalation.
Information about memory structures themselves. This could be used in follow-on exploits. An example could be the ability to read memory for the purpose of overcoming defenses such as address randomization, increasing the chances of follow-on exploits on the same system.

It is important to keep in mind that for any of these use cases to be successful, an attacker will still need the ability to execute code on a system, as these are local attacks as far as we know. For instance, targeting an end user's systems with a Javascript-enabled web browser is an obvious vector.

We foresee that attackers could use these vulnerabilities in combination with already known attack techniques. For most criminal purposes, other easier executed attack vectors are probably more effective. In the longer term, attacks using these vulnerabilities will certainly remain in use, but in isolated and more targeted cases.

What should my patch strategy be?

In general, we would advise a three-step strategy:

1. Take stock of systems with vulnerable CPUs.
2. Understand the impact of performance degradation.
3. Plan and apply patches, with a priority for Meltdown, as they become available.

Take stock of systems with vulnerable CPUs

You only need to worry about systems that are based on CPUs that are vulnerable as a result of implementing speculative execution. You should base your update strategy on an inventory of your systems. Now is a good time to add and verify CPU information to your Configuration Management Database checked against the following overview of vulnerable CPUs:

Intel: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

AMD: https://www.amd.com/en/corporate/speculative-execution

ARM: https://developer.arm.com/support/security-update

Apple: https://support.apple.com/en-us/HT208394

Other processors have not shown to be vulnerable, and in general more simple devices are not vulnerable because they simply don't incorporate speculative execution in their CPUs. Don't forget systems such as firewalls, malware analysis systems, virtual systems etc.

Understand the impact of performance degradation

Currently multiple patches have been or are being rolled out to address these vulnerabilities. These patches are applied at chip-level, the OS level and the application level. This results in a complex set of patches that need to be tested with your specific setup to determine if there will be a significant impact.

For some of the available patches it is already known that they have a performance impact, but the exact impact depends on the functionality of the application and the setup as deployed within your organisation.

While the impact on individual end users' systems can be managed as indicated above, server-side application of patches and application in virtualized environments deserve special scrutiny. Microsoft has released additional information to help users understand the potential performance impact:

https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems/

Plan and apply patches, with a priority for Meltdown

Meltdown is the variant of the new announced bugs that is fixable by patches. Be sure to patch your system as soon as one is announced for your system. To prevent errors while patching, look for the right patch for your system. It is a good idea to back-up your system, so that it can be reverted to the earlier state in case of decreased capability or functionality.

Be aware with Windows that - when you are using anti-virus (AV) software - there may be a chance that the patch will not install immediately when it's available. This is because changes to the kernel that the patch makes may influence AV software and cause issues. The patch will only install when a certain registry key is present on the system, created by AV software. Alternatively, you could create this key manually if you are certain no problems will arise, or would want to test this.

For Linux and Apple, the standard update process will apply the correct patches.

Next, the officially announced Windows, Apple and Linux updates, microcode updates - also known as firmware updates - need to be performed. Microcode updates will modify the software that is programmed into the hardware of the system (the CPUs in this case), so first make sure to perform or plan the microcode updates for your vulnerable systems before applying OS and application patches. In many cases it is not an update directly from the microprocessor vendor, but an update by a device manufacturer that includes a microcode update. The Intel microcode update, for example, does not fix the Meltdown or Spectre vulnerabilities by itself, but only offers new methods to help with a kernel-based mitigation. Thus, these updates are only useful in combination with a kernel update that knows what to do with the extra functionality. For a list of affected vendors please check the following URLs, but in most cases the microcode updates are packed with the OS update:

https://www.us-cert.gov/ncas/alerts/TA18-004A

https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=584653&SearchOrder=4

In general, it will be the case that for Spectre and Meltdown, both a microcode update AND a software update will be necessary to achieve the best possible protection. This is because the microcode updates, in general, do not completely prevent all exploits of speculative execution. In some cases, new interfaces will be available and it will be up to the operating system to make use of those new interfaces to achieve better protection. In other words: best mitigation is achieved with a combination of microcode and OS/application updates.

Finally, keep in mind that there are recent reports that the microcode updates can cause issues with other drivers or low-level software. With that in mind, it remains important to test any update related to these issues, prior to roll out.

Is there an overview available of the CPUs and devices impacted by Spectre or Meltdown?

Unfortunately, due to the wide variety of hardware that is impacted by these vulnerabilities there is no single overview of all the impacted CPUs or devices. The recommended course as action is to query your asset management inventory to obtain a list of all your devices and CPUs in use. Using this information, you can the check with the corresponding vendor to determine if your device or CPU is vulnerable. The following vendors have already proactively published a list of impacted devices or products (this is not an exhaustive overview):

Intel: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr

AMD: https://www.amd.com/en/corporate/speculative-execution

ARM: https://developer.arm.com/support/security-update

Apple: https://support.apple.com/en-us/HT208394

Google: https://support.google.com/faqs/answer/7622138

Additionally, the US CERT has published a good reference of multiple vendors with their corresponding overviews:

https://www.us-cert.gov/ncas/alerts/TA18-004A

How can I detect if I am vulnerable to these vulnerabilities?

Microsoft has released a PowerShell script to verify that the correct protections are enabled:

https://support.microsoft.com/en-hk/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in

Additionally, an independent researcher has also released a tool to check the state of the software mitigations:

https://github.com/ionescu007/SpecuCheck

Can I prevent these attacks?

First, make sure that you have an update strategy to apply the patches that mitigate these vulnerabilities. Due to the nature of the vulnerabilities it is not possible to fully prevent the attacks. This means that mitigating the impact is an important factor to consider; for example by not co-hosting data of different classification levels on the same environment.

What is the impact of these vulnerabilities on my virtual environments?

You need to apply the corresponding patches at every layer of your virtual environment. Please take into account that this also applies to containerized environments such as Docker and nested virtualization setups.

Do I need to take actions if cloud providers already deployed patches?

Yes, you need to take action to be sure the patches are also applied to your systems.

At the very minimum, you need to verify that the patches applied by your provider also cover the services and machines you are using. In some cases, you need to apply patches yourself for your own infrastructure within their cloud solution.

Other, more technical descriptions can be found on: