Yet Another Intel CPU Vulnerability - "EchoLoad"

Welcome to yet another very serious attack on intel processors.

Why very serious?

  • Because all intel processors from Pentium 4 (Prescott) up to the newest Cascade Lake are vulnerable
  • Because KASLR (kernel address space layout randomization) can not protect the kernel against the attack.
  • Because kernel space can in fact be de-randomized (“unprotected”) within tens of microseconds
  • Because it does not require intel TSX or knowledge of internal data structures
  • Because the attack is deeply rooted in the design of the microarchitecture, it cannot easily be fixed, neither in software nor hardware
  • Even on Cascade Lake with fixes for Meltdown and MDS the kernel can be de-randomized
  • The attack even works on KPTI, the Linux software mitigation for Meltdown.
  • The attack also works in restricted environments such as SGX

How about AMD? - AMD Zen is not vulnerable

Who has developed and brought us this new attack? - The University of Graz people (again) who are already well known for some studies of and finding serious attacks against x86 (mostly intel) processors. One example is “DataBounce” (which is dangerous but less so than EchoLoad.

Link to their paper → http://cc0x1f.net/publications/kaslr.pdf

My personal take: I tried to stay halfway neutral for a long time. And in fact intel processors aren’t all bad. There are some things where they are better than AMD, one important example being CPUs with low power envelope (which often is a factor in hosting).
But the more one looks, the more crappy engineering and (not really) smart “cost saving” decisions become visible. Now, we see a vulnerability which can not be mitigated, neither in hardware nor in software and, to make it even worse, it also breaks the “foundation”, kernel KASLR, upon which a lot depends. Yes, there is good news too; in fact the authors themselves suggest something like a “better KASLR”, but how long will that take to be examined, discussed, and finally brought into safer kernels? Things like that don’t happen quickly and even if we had safer kernels - for quite a few OSs at that - within a reasonably short time frame, there still is the issue of lots and lots of older kernel which won’t be updated (just think of the billions of plastic boxes out there).

TL;DR Buy AMD only

(This is my first thread here, so please be mild and kind with me …)

3 Likes

Thanks for sharing!

Sigh… Let’s add this one to the list

1 Like

At a certain point with these I think cloud providers that still have intel deployed should just be like “You know what, you’re on an Intel CPU. Take the risk or don’t, we’re done trying.”

1 Like

It’s even worse.

I myself wasn’t too concerned because, oh well, if you need security you get a dedi and that’s it.

That new attack however is feasible even with Javascript! and that means that, no, you are not safe with a dedi anymore, especially when you are serving a web site.

That’s also a major reason why I changed my stance from being “mildly concerned” by all the attacks to straight out “Buy AMD! Period”.

But there is an ugly but: why did intel create that clusterf_ck? At least a very major part of the answer points to us, the consumers. I’ll elaborate on that if there is interest in that discussion.

Oh boy, I wonder if we’ll see stuff like this with AMD, let’s say 5-10 years down the line.

1 Like