xorl %eax, %eax

Thoughts on Meltdown & Spectre

with 3 comments

2018 started with some unique low-level exploitation techniques disclosure. People that never cared about processor architecture suddenly explain how speculative execution, advanced side-channel analysis, and cache level works in modern high-performance processors, others confuse the different architecture design flaws, media and software vendors are heavily controlled by big processor manufacturers, Linus accepts patches with up to 30% performance impact without a question, and within that chaos we still miss some crucial details. In this post, I will give my thoughts on the following five domains regarding the Meltdown & Spectre exploitation.

  • Real-world impact
  • The victims/targets
  • Media manipulation
  • Nation-state
  • Mitigations

Real-world impact
For any of the disclosed exploitation methods, there is very limited real-world impact (yes, even for the JavaScript one on browsers with SharedArrayBuffer). The reason for this is that those attacks cannot be easily automated. They are definitely feasible, but they require manual intervention to provide any value to the attacker. Consequently, their use would only be useful on targeted attacks. But even in this case, why would an attacker prefer to read arbitrary memory using this extremely slow technique instead of exploitation a privilege escalation vulnerability and get much faster access to all system resources? One could argue because it is more covert. Well, there are some actual attack use cases and this is my next domain.

The victims/targets
The only real victim that this attack is more valuable than privilege escalation attacks is shared hosting providers. Whether that is virtual machines, containers, or anything similar. Those exploitation techniques break the sole business model of those companies. Huge players like Amazon, Google, Microsoft, etc. are selling exactly what Meltdown & Spectre proved that it doesn’t exist, high quality isolation between shared resources. And that brings us to the next domain.

Media manipulation
All of those big players, including manufacturers such as Intel, AMD, and the rest of the affected vendors, did a first-class crisis management when it comes to managing the reputation impact and press statements. They should probably be giving trainings on how to do this. You would expect that an attack that obliterates your core business selling point would result in massive stock price drops, media chasing the board all over the world, people moving away from those vendors, executives getting fired… Yet, nothing happened. From the business perspective this is a remarkable work of crisis management, but from the consumer perspective this is an alarming level of media manipulation power.

Talking about power, let’s talk about nation-states. Those attacks were not really new. Dave Aitel released this Immunity paper from 2014 that pretty much implements a variant of those exploitation techniques. If we move even further back, we have this paper from 1995 which goes through multiple security flaws of the x86 architecture, including the pre-fetching one. The latter document also contains an interesting sentence in its introduction.

This analysis is being performed under the auspices of the National Security Agency’s Trusted Product Evaluation Program (TPEP).

So, we know that NSA knew about those design flaws for at least 23 years. Realistically speaking, it is safe to assume that they would have tried to exploit them. Recently after the public disclosure of the attack the ShadowBrokers started offering some (allegedly) 0day exploits for those flaws claiming to be part of NSA’s toolkit.

Just to be clear, I totally endorse NSA, or any other nation-state for that matter, not disclosing them. They had already disclosed the research paper so the entire world knew about them (including Intel, AMD, and the rest). A tool that allows you to bypass the false sense of memory isolation a cloud provider offers would be extremely valuable for any offensive security team. It is the companies’ fault that they did not fix it. Nevertheless, it was worth mentioning. And talking about fixing…

There are a few different mitigations being proposed or already implemented. Let’s briefly go through them…

  • On the OS side we have we the KAISER/KPTI implementation which basically separates the kernel and user-space pages requiring TLB flushes (reloading of CR3 register or the use of Process Context Identifier (PCID) where available). Depending on the application, this can have major performance impact but, on the other hand, it also prevents a large number of exploitation techniques that were already used in the wild. So, security wise it is great, but business wise it will require extra funding for scaling for most companies. And guess what? The manufacturers of those processors are not held accountable for this (they should in my opinion as it was a known issue for decades).
  • The other proposed mitigation was the use of LFENCE instruction to literally stop speculative execution on specific code paths. A clever approach which however is hard to implement and deploy in the real world if you don’t want to have massive performance impact.
  • Intel issued a microcode update that also adds some new capabilities. Those are the IBRS (Indirect Branch Restricted Speculation), STITBP (Single Thread Indirect Branch Prediction), and IBPB (Indirect Branch Predictor Barrier). All can be used to control when branch prediction and indirect jumps are allowed. However, it brings another interesting attack vector… If Intel can dynamically reprogram their processors via a UEFI channel, maybe attackers can too. Sounds like an interesting research area now that the updates are out.
  • The last one is to recompile the code with a compiler that adds the concept of “return trampolines” (retpoline) which ensures that indirect near jumps and call instructions are bundled with some details about the target of the branch to avoid the cases of branch target injection attacks of Spectre. Again, good idea but expecting to recompile all binaries using this is not a trivial operation.

As a conclusion, the Meltdown & Spectre exploitation techniques sound like one of the biggest cover-up stories of the infosec community. Known for 20+ years, breaking core business models, nation-states researching them for decades… And yet… No repercussions or even media pressure to any of the involved parties behind them.

Written by xorl

January 10, 2018 at 10:40

Posted in security

3 Responses

Subscribe to comments with RSS.

  1. > Just to be clear, I totally endorse NSA, or any other nation-state for that matter, not disclosing them.

    Now why would you do that?


    June 4, 2021 at 04:08

  2. Because from their side of the story those would be some pretty powerful capabilities.


    June 18, 2021 at 11:17

  3. I see.

    I took what you said to mean that you agreed with their side.

    I believe they should be disclosing them as it allows everyone’s security to improve. But it is true that their offensive capabilities would go down if they don’t hog vulnerabilities.


    June 29, 2021 at 05:30

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: