Tag Archives: cpu

Vuln mitigation and INtel MDS – the spectre looms

Spectre and Meltdown a have been with us for just over a year now and even with all the predictions of dire consequences, we have yet to see any in-the-wild code snippets or attacks beyond theoretical POCs. So the question to ask is whether we should be losing a lot of hardware performance (most of the associated mitigations have performance impacts) for the sake of potentially theoretical security issues.

I recently had a chat to a client about in what order vulns should be mitigated in their organization and what strategy to use in optimizing patch deployment. Admittedly the most popular, and common option is to approach this from the view of criticality. It’s rated critical so we should fix it? Well, not necessarily: there are many variables which impact the potential order of fix for your specific site or organisation. Factors like nature of systems, impact trend of the vuln, age and type of vuln, type of application, patching intervals, is it remote exploitable, reach and platform types can factor in more than just the CVSS score.

This class of CPU architectural issues is a specific case in point. Yes theoretically it’s possible to perform the exploits but have there been any practical implementations yet? No? So do we really need to patch? When there’s large costs associated with critical data loss and compromise, the choice is a difficult one and cuts a fine line.

And this class of exploit is not slowing down. A new Intel-focussed vuln called MDS (that apparently does not affect ARM or AMD platforms) comprising 4 related techniques was released in mid-May, the 3rd such announcement this year already.

Side channel attacks seem to be a dime a dozen these days, but again, this vuln (or class of vulns) is listed as being complex to exploit and possibly as theoretical as all the others have been. Apple’s immediate response was to switch off SMT (commonly know as hyperthreading) which results in an approximate 40% performance hit. As was Google’s response for Chrome OS. I can just see Homer saying “Duh?”.

Disabling HT/SMT by the way, does not completely mitigate MDS …

Once again, mitigations include hardware, firmware microcode and software/OS components, all of which need to be aligned to get full protection. Notwithstanding patching strategies and other blockers in rolling out co-ordinated fixes like this, what will the practical reach be for these patches? Servers will languish with delays and desktops (and other IOT devices) may never even get the firmware fixes.

So it’s all a bit wishy washy at the moment. Time for some risk analysis.

Meltdown and Spectre – hardware gone wild!

We’ve had some big doozies over the last 2 years from a security point of view, but the latest CPU hardware-related bugs called Spectre and Meltdown, that started making headlines early last week, surely take the cake. One has to be careful though in classifying these as bugs, because those affected would say these were conscious design choices in their CPUs, although they must have seen the potential side-effects of their choices.

So what are we actually talking about here?

First, Google’s Project Zero was started in 2014 and is a group of security analysts dedicated to finding vulnerabilities in IT systems. Some of the biggest vulnerabilities in IT systems over the last few years, have been found by GPZ so when they talk, people tend to listen.

GPZ found some interesting cache timing attacks in CPUs in the 1st half of 2017 and advised the affected  vendors on June 1st 2017. The attacks (can) effectively lead to leaked information from kernel memory, a very bad situation to say the least. Public inclusion was limited to give all vendors time to come up with resolutions however in December, another security group caught wind of the issues, released their findings and as of the beginning of this year, the rest is history.

The issues exist in most CPUs (especially Intel) going back to 1995 and are classed into 2 groups:

  • Meltdown
  • Spectre type 1 and 2

Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

Meltdown has a fairly straightforward fix (which has been released by most OS vendors already) however there can be a performance penalty (sometimes significant) depending on the configuration and circumstances of systems. Intel specifically has tried to downplay the extent of performance degradation, but it is so severe in some cases, that affected vendors are advising not to implement the fixes.

Amazon Web Services (AWS) applied their meltdown patches this weekend past and many of their large customers have been showing light to medium performance impacts.

Note that these issues affect everything from desktop PCs, embedded and mobiles to servers and cloud systems.

Microsoft have advised that older processors with older versions of Windows are likely to suffer more. In addition, Microsoft has pulled their patch for PC systems based on AMD processors due to a compatibility issue.

Another aspect of the Meltdown issue on Windows OS’s is that certain AntiVirus packages have very deep hooks into the kernel to detect rootkit and other kernel-related malicious activity. And these are not playing nice with the patches leading Microsoft to implement a registry key system requiring AV vendors to set a key that confirms their compatibility with the patch. Messy mutch?

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre.

Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. Most vendors do NOT have fixes for Spectre yet at this moment or at best, existing fixes are incomplete. The reason for this is that the fixes require co-ordination between firmware, CPU microcode and operating system – a delicate and difficult balancing act requiring all vendors to work very closely together.

So where does that leave the general public? On the one hand, Meltdown is mostly sorted but with performance penalties probable and Spectre fixes are an ongoing project leaving unprotected systems at the mercy of potential 0-day attacks.

Most users or organisations running endpoint and perimeter security systems should be ok as these have been retrofitted with protections against potential attacks.

But the situation remains pretty fluid at the moment and we’re likely to see a lot more activity on this over the next few weeks. As usual, patch everything that can be patched.