1

Reading up on Spectre and Meltdown attacks again, I don't get why they were hyped so much.

These are cache attacks that take advantage of the instruction pipeline processing implementation in addition to the cache implementation. So this is just another variation of the cache attacks. Why are these two attacks so hyped? Are they that much better? Do they make things easier?

  • Previous attacks extracted AES keys and other sensitive material from processes.
  • There have been Javascript based cache attacks before haven't they?
  • Attacks have been made to work across cores before.
  • Previous attacks also work on machines with multiple CPUs.

I understand these two variants make the attack much more easier and more controlled? Is that the reason?

Tom K.
  • 7,913
  • 3
  • 30
  • 53
stflow
  • 95
  • 5
  • Note that previous attacks tend to be limited in what they are capable of doing. Many side-channel attacks are against insecure _operations_ like RSA modulus exponentiation or AES S-box lookups. The difference is these attacks can be used to read arbitrary memory, regardless of whether or not it is being used insecurely. – forest Mar 17 '18 at 01:06
  • Maybe do some proper __research__ as well? The academic papers linked from the spectre website discussed their significance.... – billc.cn Mar 19 '18 at 17:32

2 Answers2

4

There are a few things that make Spectre and Meltdown different from historical cache attacks. Some are specific to the attacks, and some are simply a consequence of the changing computing environment.

Stuff that's different about the attacks:

  1. They're really hard to fix. These are hardware problems, and in the case of Spectre are hardware design problems rather than implementation bugs. Fixing hardware is slow, expensive, and hard to verify. You can't just fix the problem with software updates, the way you can with most security bugs. The "patch" for Meltdown is more accurately described as a work-around than a fix (rather than fixing the underlying problems of userspace programs being able to read arbitrary kernel memory, you just un-map the kernel from userspace programs so there's nothing to read, and eat the performance cost of a context switch on every system call). Spectre doesn't even have that; the closest we've got is things like degrading the precision of JS timers (which may negatively impact some legitimate code) to make it harder (but not impossible) to detect the timing differences.
  2. They're fast, reliable, and easy to carry out. Any language that supports high-precision timers and contiguous-memory arrays with arbitrary indexing (i.e. approximately all of them) can be used, in a very short block of code that is easy to port from one language to another, for successful exploitation. They can be used to extract quite a lot of should-be-hidden data (easily KBs, often MBs or even 100s of MBs) every second. That's a big difference from older attacks that often could only maybe get anything useful, if they had a good long while to work on it.
  3. They allow targeting arbitrary memory addresses, and don't rely on waiting until the processor is doing the thing you want to inspect. Previous cache attacks were mostly focused on seeing what was in other programs' cache lines, which means the attacker couldn't pick and choose what they got. If you know the other program is doing crypto, you might be able to extract the key, but if you mess up your timing (see the point above) or can't force the data you want to access to be accessed (and thus in cache) when your attack is running, too bad. However, Spectre and Meltdown allow reading arbitrary memory addresses of your choosing, which means you can do things like walk data structures to find exactly the information you are looking for.

Stuff that's different about the computing environment:

  1. Cloud computing is common. It is far more typical now, than at any time in the recent past, for two unrelated and mutually-untrusted entities to be running arbitrary code on the same physical machine. Just as processes divide JS sandboxes from the rest of their address space and OSes divide process address spaces from each other, hypervisors divide VM physical address spaces from each other. The very premise of safely in the cloud ("running code on other people's computers") is built on these divisions, and Spectre/Meltdown breaks them.
  2. JavaScript is ubiquitous and useful. What was once a toy language with no use for high-precision timers or typed and bounded arrays has become a very powerful language with most of the features found in other application programming languages. Browsers cheerfully execute code from arbitrary and often untrusted sources (web servers), relying on the JS sandbox to prevent (most) malicious uses of this power. For attacks like Spectre and Meltdown, which bypass the sandbox's protection and can be written in JS, it is an ideal attack vector usable against nearly all end-user machines.
CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • 1
    +1. Note that, while reducing JavaScript timing precision is useful, JIT can still be used to create tight loops for timing. – forest Mar 17 '18 at 01:48
0

The significance lies in the prevalence of processors exposed to the respective vulnerabilities. (1)(2)(3)

Most of Intel's and AMD's CPUs are in some form vulnerable to Spectre and/or Meltdown and the combined market share of the two companies in the non-mobile world is pretty much 100% for x86 processors.

Distribution of AMD and Intel x86 computer processors worldwide, from 2012 to 2017, by quarter Source

Besides personal computers, a lot of mobile devices (their processors also use speculative execution), cloud infrastructures (the cloud is everywhere) and virtual machines (again everywhere) are (in part) vulnerable as well.

It is fair to say, that we have very rarely seen attacks like Spectre and Meltdown that can be applied to as many devices regardless of their operating system.

Let's add up, folks! What's vulnerable?
All non-mobile personal devices, a lot of mobile devices, a lot of servers, a big chunk of cloud infrastructure and virtual machines.

Do you feel the significance by now?

Tom K.
  • 7,913
  • 3
  • 30
  • 53