{"id":14732,"date":"2019-03-01T09:10:02","date_gmt":"2019-03-01T17:10:02","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2019\/03\/01\/news-8481\/"},"modified":"2019-03-01T09:10:02","modified_gmt":"2019-03-01T17:10:02","slug":"news-8481","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2019\/03\/01\/news-8481\/","title":{"rendered":"Spectre, Google, and the Universal Read Gadget"},"content":{"rendered":"

Credit to Author: Christopher Boyd| Date: Fri, 01 Mar 2019 16:43:37 +0000<\/strong><\/p>\n

Spectre, a seemingly never ending menace to processors, is back in the limelight once again thanks to the Universal Read Gadget. First seen at the start of 2018, Spectre emerged alongside Meltdown as a major potential threat to people\u2019s system security.<\/p>\n

Meltdown and Spectre<\/h3>\n

Meltdown targeted Intel processors and required a malicious process running on the system to interact with it. Spectre could be launched from browsers via a script. As these threats were targeting hardware flaws in the CPU, they were difficult to address and required BIOS updates and some other things to ensure a safe online experience. As per our original blog<\/a>:<\/p>\n

\n

The core issue stems from a design flaw that allows attackers access to memory contents from any device, be it desktop, smart phone, or cloud server, exposing passwords and other sensitive data. The flaw in question is tied to what is called speculative execution<\/a>, which happens when a processor guesses the next operations to perform based on previously cached iterations.<\/em><\/p>\n

The Meltdown variant only impacts Intel CPUs, whereas the second set of Spectre variants impacts all vendors of CPUs with support of speculative execution. This includes most CPUs produced during the last 15 years from Intel, AMD, ARM, and IBM.<\/em><\/p>\n<\/blockquote>\n

This is not a great situation for everyone to suddenly find themselves in. Manufacturers were caught on the backfoot and customers rightly demanded a solution.<\/p>\n

If this is the part where you\u2019re thinking, \u201cWhat caused this again?\u201d then you\u2019re in luck.<\/p>\n

Speculative patching woes<\/h3>\n

The issues came from something called \u201cspeculative execution.” As we said in this follow up blog<\/a> about patching difficulties:<\/p>\n

\n

Speculative execution is an effective optimization technique used by most modern processors to determine where code is likely to go next. Hence, when it encounters a conditional branch instruction, the processor makes a guess for which branch might be executed based on the previous branches\u2019 processing history. It then speculatively executes instructions until the original condition is known to be true or false. If the latter, the pending instructions are abandoned, and the processor reloads its state based on what it determines to be the correct execution path.<\/em><\/p>\n

The issue with this behaviour and the way it\u2019s currently implemented in numerous chips is that when the processor makes a wrong guess, it has already speculatively executed a few instructions. These are saved in cache, even if they are from the invalid branch. Spectre and Meltdown take advantage of this situation by comparing the loading time of two variables, determining if one has been loaded during the speculative execution, and deducing its value.<\/em><\/p>\n<\/blockquote>\n

Four variants existed across Spectre and Meltdown, with Intel, IBM, ARM, and AMD being snagged by Spectre and \u201cjust\u201d Intel being caught up by Meltdown.<\/p>\n

The vulnerabilities impacting CPUs (central processing units) made it a tricky thing to fix. Software alterations could cause performance snags, and hardware fixes could be even more complicated. A working group was formed to try and thrash out the incredibly complicated details of how this issue would be tackled.<\/p>\n

In January 2018, researchers stressed the only real way to solve Spectre was redesigning computer hardware from the ground up. This is no easy task. Replace everything<\/a>, or suffer the possible performance hit from any software fixes. Fairly complex patching nightmares abound, with operating systems, pre\/post Skylake<\/a> CPUs, and more needing tweaks or wholesale changes.<\/p>\n

Additional complications<\/h3>\n

It wasn\u2019t long before scams started capitalising on the rush to patch. Now people suddenly had to deal with unrelated fakes, malware, and phishes on top of actual Meltdown\/Spectre threats.<\/p>\n

Alongside the previously mentioned scams, fake websites<\/a> started to pop up, too. Typically they claimed to be an official government portals, or plain old download sites offering up a fix. They might also make use of SSL, because displaying a padlock is now a common trick of phishers. That’s a false sense of security\u2014just because there\u2019s a padlock, doesn\u2019t mean it\u2019s a safe site. All it means is the data on it is encrypted. Beyond that, you\u2019re on your own.<\/p>\n

The site in our example offered up a zipfile. Contained within was SmokeLoader, well known for attempting to grab additional malicious downloads<\/a>.<\/p>\n

\"SmokeLoader\"<\/a><\/p>\n

Click to enlarge<\/p>\n

Eventually, the furore died down and people slowly forgot about Spectre. It\u2019d pop up again in occasional news articles, but for the most part, people treated it as out of sight, out of mind.<\/p>\n

Which brings us to last week\u2019s news.<\/p>\n

Spectre: What happened now?<\/h3>\n

What happened now is a reiteration of the \u201cit\u2019s not safe yet\u201d message. The threat is mostly the same, and a lot of people may not need to worry about this. However, as The Register<\/a> notes, the problem hasn\u2019t gone away and some developers will need to keep it in mind.<\/p>\n

Google has released a paper titled, unsurprisingly enough,\u00a0<\/span>“Spectre is here to stay: An analysis of side-channels and speculative execution.”<\/p>\n

The Google paper<\/h3>\n

First thing\u2019s first: It\u2019s complicated, and you can read the full paper [PDF] here<\/a>.<\/p>\n

There\u2019s a lot of moving parts to this, and frankly nobody should be expected to understand everything in it unless they\u2019re working in or around this in some capacity. Some of this has already been mentioned, but it’s already about 700 words or so ago so a short recap may be handy:<\/p>\n

    \n
  1. Side channels are bad. Your computer may be doing a bunch of secure tasks, keeping your data safe. All those bits and pieces of hardware, however, are doing all sorts of things to make those secure processes happen. Side channel attacks come at the otherwise secure data from another angle, in the realm of the mechanical. Sound, power consumption, timing between events, electromagnetic leaks, cameras, and more. All of these provide a means for a clever attacker to exploit this leaky side channel and grab data you\u2019d rather they didn\u2019t.<\/li>\n
  2. They do this in Spectre\u2019s case by exploiting speculative execution. Modern processors are big fans of speculative execution, given they make use of it extensively. It helps improve performance, by making guesses about what programs will do next and then abandoning if it turns out that doesn\u2019t happen after all. Conversely, the retained paths are deployed and everything gets a nice speed boost. Those future potential possibilities is where Spectre comes in.<\/li>\n
  3. As the paper says, \u201ccomputations that should never have happened\u2026allow for information to be leaked\u201d via Spectre. It allows the attacker to inject \u201cdangerously speculative behaviour\u201d into trusted code, or untrusted code typically subjected to safety checks. Both are done through triggering \u201cordinarily impossible computations\u201d through specific manipulations of the processor\u2019s shared micro-architectural states.<\/li>\n<\/ol>\n

    Everything is a bit speed versus security, and security lost out. The manufacturers realised too late that the speed\/security tradeoff came with a hefty security price the moment Spectre arrived on the scene. Thinking bad actors couldn\u2019t tamper with with speculative executions\u2014or worse, not considering this in the first place\u2014has turned\u00a0<\/span>out to be a bit of a disaster.<\/p>\n

    The paper goes on to list that Intel, ARM, AMD, MIPS, IBM, and Oracle have all reported being affected. It\u2019s also clear that:<\/p>\n

    \n

    Our paper shows these leaks are not only design flaws, but are in fact foundational, at the very base of theoretical computation.<\/em><\/p>\n<\/blockquote>\n

    This isn\u2019t great. Nor is the fact that they estimate it\u2019s probably more widely distributed than any security flaw in history, affecting \u201cbillions of CPUs in production across all device classes.\u201d<\/p>\n

    Spectre: no exorcism due<\/h3>\n

    The research paper asserts that Spectre is going to be around for a long time. Software-based techniques to ward off the threat will never quite remove the issue. They may ward off the threat but add a performance cost, with more layers of defence potentially making things too much of a drag to consider them beneficial.<\/p>\n

    The fixes end up\u00a0<\/span>being a mixed bag of trade-offs and performance hits, and Spectre is so variable and evasive that it quickly becomes impossible to pin down a 100 percent satisfactory solution. At this point, Google\u2019s \u201cUniversal Read Gadget\u201d wades in and makes everything worse.<\/p>\n

    What is the Universal Read Gadget?<\/h3>\n

    A way to read data without permission that is for all intents and purposes unstoppable. When multiple vulnerabilities in current languages run on the CPU, it allows construction of said read gadget and that’s the real meat of Google’s research.\u00a0Nobody is going to ditch speculative execution anytime soon, and nobody is going to magically come up with a way to solve the side channel issue, much less something like a Universal Read Gadget.<\/p>\n

    As the paper states,<\/p>\n

    \n

    We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations…as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels.<\/em><\/p>\n<\/blockquote>\n

    On the other hand, it\u2019s clear we shouldn\u2019t start panicking. It sounds bad, and it is bad, but it\u2019s unlikely anyone is exploiting you using these techniques. Of course, unlikely doesn\u2019t mean unfeasible, and this is why hardware and software organisations continue to wrestle with this particular genie.<\/p>\n

    The research paper stresses that the URG is very difficult to pull off.<\/p>\n

    \n
    \n
    \n
    \n

    The universal read gadget is not necessarily a straightforward construction. It requires detailed knowledge of the \u03bc-architectural characteristics of the CPU and knowledge of the language implementation, whether that be a static compiler or a virtual machine. Additionally, the gadget might have particularly unusual performance and concurrency characteristics<\/em><\/p>\n<\/blockquote>\n

    Numerous scenarios will require different approaches, and it lists multiple instances where the gadget will potentially fail. In short, nobody is going to come along and Universal Read Gadget your computer. For now, much of this is at the theoretical stage. That doesn’t mean tech giants are becoming complacent however, and hardware and software organisations have a long road ahead to finally lay this spectre to rest.<\/p>\n<\/p><\/div>\n<\/p><\/div>\n<\/p><\/div>\n

    The post Spectre, Google, and the Universal Read Gadget<\/a> appeared first on Malwarebytes Labs<\/a>.<\/p>\n

    https:\/\/blog.malwarebytes.com\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Credit to Author: Christopher Boyd| Date: Fri, 01 Mar 2019 16:43:37 +0000<\/strong><\/p>\n\n\n\n
    <\/a><\/td>\n<\/tr>\n
    A recently released paper by Google has resurrected the spirit of Spectre, a seemingly never-ending threat to most makes of processor. We take a look at what this means, and what the Universal Read Gadget means for most technology users.<\/p>\n

    Categories: <\/p>\n