Jean-Baptiste Bres

Chief Information Security Officer

💡 Understanding Meltdown and Spectre

08/01/18 20:38 Filed in: Security | IT Infrastructure | Cloud | Articles

As an executive or senior manager, what should I know and what should my company be doing about Meltdown and Spectre? If you are not an IT Security specialist and you have been trying to understand what all the fuss is about — you are probably struggling to find articles that are not overly technical or too generic. Hopefully, this one will be answer your questions.

What are Meltdown and Spectre?

Meltdown and Spectre are new attack techniques build upon some recently discovered design flows in moderns micro-processors.


2018-01-Meltdown-1

Now, this bit is a little bit technical, so if you feel that you don’t really want to know how these attacks are working, and want to focus on the risks for you and how to remediate them, feel free to skip to the next section.

Speculative execution has been a feature of micro-processors for at least a decade. In a nutshell, micro-processors execute instructions, as per the algorithm that define an application. Sometime, the next instructions to be executed by the processor are dependant of the result of the previous one. This is call a “branch”, because depending on the result of the previous instructions, the program can branch toward one set of instructions or another. In such cases, modern processors make a “guess” to potentially save time. They will execute one of the possible branch options in advance (typically based upon the last step of the same branch’s previous execution). One the previous instruction is finished and the processor finally know which branch it should actually follow, either the guess made earlier was correct and the processor has already executed the next steps (and hence, gained time), either the guess was wrong, in which case the pre-executed instructions are tossed away and the correct ones are being executed instead.

The fact that, when the guess is wrong, invalid speculations are tossed is a key attribute exploited by Meltdown and Spectre. Despite the clearing of invalid execution results, data from the execution may be retained in the processor caches. These data in those caches are what both attacks are targeting.

Because these techniques are largely applied by all processors, the threat applies (with variation) to most modern operating systems (Windows, Linux, Android, iOS, MacOS, FreeBSD, etc.).

Meltdown and Spectre were discovered in June 2017 by joint efforts of Google's Project Zero, Cyberus Technology and the Graz University of Technology. After affected hardware and software vendors had been made aware of the issue in July 2017, the two vulnerabilities were made public jointly, on January 3, 2018, several days ahead of the coordinated release date of January 9, 2018 as news sites started reporting about them. As a result, patches were not available for some platforms when the vulnerabilities were disclosed.

What would be the impact of a successful attack?

The impact of a successful attack using one of these techniques would be an unauthorised access (read only) to the processor cached memory. By nature, the processor cached memory can contain any information, from irrelevant temporary code to, occasionally, customer data or password, so access to that memory by a malicious individual could potentially be a disaster.

In some specific cases, the attack could also be used to obtain limited escalation of privileges on the targeted devise. This means that the attacker might use these attack to gain additional power and do more damages.
A naturally mitigating factor is that these exploits require local code execution, which means that the attacked need to have an existing access to the devise to exploit the attack.

The table below details the similarities and differences between the two techniques:

2018-01-Meltdown-2
To understand the potential impact of these attack techniques, you need to understand what is their value to attackers. In the case of Meltdown and Spectre, they are attractive to malicious groups or persons because the attack surface is nearly unprecedented. Pretty much every computer, mobile phone, electronic devise is affected, as there are processors in everything today. Even printers, connected TV, online cameras are potentially at risk. In addition, the attacks are relatively new, and the impacts (privilege escalation and leaks of sensitive memory) are detrimental.

In the case of Spectre, a specific technique that allows an attacker to cross virtual machine boundaries is of particular interest, because it could be used for a hacker to attack other tenants sharing the same public cloud service. More about that later.

Additionally, both Meltdown and Spectre are exceptionally hard to detect as they do not leave forensic traces or halt program execution. This makes detection, post-infection investigations and attack attribution much more complex.

Now, all this sounds frightening – and it rightfully is. But understanding a bit more how the different parts of your infrastructure are exposed is important to appropriately assess your risk and then define an adequate plan of action to remediate it.

What is the level of risk for my infrastructure?

Each infrastructure is different, and has such you should take the information in this section with a grain of salt. Your IT team has probably done their own analysis and they are your local specialists. You should rely on them. The assessment below is more of a generic view. It is based on the assumptions that you already have a mature information security framework in place and focus on what actual “holes” these 2 new attacks create in your framework.

What we will review is the risk based on the type of infrastructure and its support model. Of course, because it is likely that your organisation uses multiple infrastructures, it is important to understand for each of them what is the level of risk. It will help to prioritise actions.

SaaS

Risk level: Various
SaaS come in various shapes and sizes, so their level of exposure will depend on their underlying infrastructure, which, as a customer, you will probably have not access or idea about. The best is to ask each provider to assess their own risk and decide with them the appropriate plan if needed.
A lot of SaaS services rely on public cloud, so make sure they check with their own providers that they are appropriately covered.

Public Cloud

Risk level: High
If you are using public cloud for critical infrastructures, and especially if these services hold critical data, you might want to consider them as you highest priority when it comes to Meltdown and Spectre. A specific technique of the Spectre attack allows an attacker to cross virtual machine boundaries.

Public cloud solutions are shared services. This means that – even if you have your own “tenant” that is logically segregated from other customers – you and other customers might be sharing the same physical servers. One physical server can run multiple virtual machines at the same time. For you, as a customer, it is invisible. You get access to a virtual server and it is dedicated to you. For the cloud provider, it is an economy of scale. With a single physical host, they run multiple servers for multiple customers. This helps them to get their prices low.

Normally, each virtual machine on the same physical server are fully segregated. You cannot access other tenants’ machines, and they cannot access yours. Unfortunately, using the Spectre attack allow to bypass the segregation. A malicious person could use the attack to access the content of the physical devise processor cache and access the data of other tenants.

Because Public Cloud are accessible to everyone, including malicious groups and individuals, and since you have no way to know who is sharing the physical servers that are hosting your virtual machines, it is easy to understand that the Spectre attack could be disastrous if executed on one of the servers hosting also used by your tenants. It is unlikely that the attackers would be specifically targeting you – as they also have no way to know who else is sharing the same servers – but nevertheless they would potentially gain access to your data.

Internally Hosted Servers

Risk level: Moderate
If you already have in place some good governance around your servers' access and protection, your exposure should be limited. The important thing is that access to the devise is required to execute these attacks, and only a handful of trusted and qualified staff members should be able to access them. While servers are exposed to the same risk from web browsers than workstations (see the Workstations section), access to the web from a server should be limited, and administrators should know better than use a server to browse unreliable website. So you should be good from that side.

Apply the patches as soon as possible, but keep in mind that performance impacts have been noted, so plan carefully and don't rush them, except if you believe that you are at immediate risk.

Workstations and mobile devises

Risk level: High
As we mentioned previous, a naturally mitigating factor is that these exploits require local code execution, which means that the attacked need to have an existing access to the devise to exploit the attack. This means that in order to use these exploits an attacker would require an existing access to the device, and that these exploits cannot be used to gain access to the devise remotely.

The main issue with workstations and mobile devises at this point seems to be these attacks can be use via a web browser using JavaScript. JavaScript is used by modern websites to execute code from a webpage on the user computer. It is what makes all these online services, such as Office 365, Gmail, and all other external and internal online tools greats and so full of capabilities. But of course, set-up on a malicious website, it can be used by someone that do not have access to a devise to execute code on that devise. So potentially, if a user was to navigate on a trapped website, a hacker could intercept part of the data from the user computer using these attacks.

The main issue is that the main web browsers are not providing patches as per today. It will sure come in the next few days - some are already planned. Until then some (temporary) options exists. See the contingency section for more details.

What can be done to protect my infrastructure?

Contingencies exist at multiple levels and are currently being implemented by all vendors. Unfortunately, a lot of them are still being developed and as such are not available just yet. They will be in the next few days.
Once they have identified the risks associated to your various architectures, your IT team can now plan and deploy the various patches that are needed. The table below will show you what you need to consider. Be careful, as some of these patches have adverse side effects.

Pasted Graphic 1


Status below are as per 8/01/2018

Servers patches

✔ Microsoft Server 2016, 2012 R2 and 2008R2: patch available. However the patch will apply only if your antivirus has been updated and is compatible with it. A list of compatible antivirus is available on this site. The patch is also known to have some performance reduction.
✔ Linux Red Hat Server: patch available. The patch is also known to have some performance reduction.
✔ Linux Debian Server: patch available. The patch is also known to have some performance reduction.
✔ Linux Suze Server: patch available. The patch is also known to have some performance reduction.

Workstations & Mobile devices patches

✔ Microsoft Windows 10: patch available. However the patch will apply only if your antivirus has been updated and is compatible with it. A list of compatible antivirus is available on this site. The patch is also known to have some performance reduction, although Intel suggested they will not be noticeable on workstations.
✖ Previous version of Microsoft Windows are expected to be patched on 9/01/2017.
✔ Apple Mac OS High Sierra: patch available
✖ Previous versions of Apple Mac OS are planned to be patched.
✔Google Chromebook: patch available
✔ Linux RedHat: patch available. The patch is also known to have some performance reduction, although Intel suggested they will not be noticeable on workstations.
✔ Linux Ubuntu: patch available. The patch is also known to have some performance reduction, although Intel suggested they will not be noticeable on workstations.
✔ Linux Debian: patch available. The patch is also known to have some performance reduction, although Intel suggested they will not be noticeable on workstations.
✔ Linux Suze: patch available. The patch is also known to have some performance reduction, although Intel suggested they will not be noticeable on workstations.
✔Apple iOS (iPhone and iPad): patch available.
✔✖ Google Android: patch available. Unfortunately, distribution of Android patches is dependent on device manufacturer and/or of the carrier, so not all devises will have the patch available

Application patches

The main applications to look for are web browsers:
🚩 Google Chrome will be patched on January 23 (version 64). Until then, you can activate an experimental functionality called site isolation to protect your browser.
🚩 Mozilla Firefox is working on a patch for its current version (version 57). Until then, you can activate two timing-related mitigations.
✔ Microsoft Internet Explorer and Edge: patch available. However the patch will apply only if your antivirus has been updated and is compatible with it. A list of compatible antivirus is available on this site.
✖ Apple Safari is working on a patch.

Hypervisors patches


✔ VMWare: patch available
✖ Xen: no patch available
✖ Cisco UCS: will be patched on 18/02/2018

Firmware patches


See your hardware vendor for details



Sources






Disclamer
This article is not legal or regulatory advice. You should seek independent legal advice on your legal and regulatory obligations. The views and opinions expressed in this article are solely those of the author. These views and opinions do not necessarily represent those of StatePlus or its staff.