Return to Level1Techs.com

Intel FUBAR ... again - Kernel memory leak in nearly every Intel CPU of the last decade (Spectre hits everyone, Meltdown still Intel exclusive)

intel
mega_thread
bug

#1

Overview about the situation:

https://www.anandtech.com/show/12214/understanding-meltdown-and-spectre

Updated FAQ:

TL;DR:

@wendell, am I wrong or does this look very very bad?


So what is Meltdown / Spectre

https://meltdownattack.com/


Here is what Intel’s BS… sorry, PR-team wants to tell you:

and what AMD has to say about that:

https://www.amd.com/en/corporate/speculative-execution


Also this happened but doesn’t have anything to do with whatever of course…


older material

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table

https://youtu.be/ewe3-mUku94?t=29m52s

Address Space Layout Randomization (ASLR) is fundamentally broken on modern hardware due to a side-channel attack on the Memory management unit, allowing memory addresses to be leaked from JavaScript. This talk will show how.

Address space layout randomization (ASLR) has often been sold as an
important first line of defense against memory corruption attacks
and a building block for many modern countermeasures. Existing
attacks against ASLR rely on software vulnerabilities and/or on
repeated (and detectable) memory probing.

In this talk, we show that neither is a hard requirement
and that ASLR is fundamentally insecure on modern cache-
based architectures, making ASLR and caching conflicting
requirements (ASLR xor Cache, or simply AnC). To support
this claim, we describe a new EVICT+TIME cache attack
on the virtual address translation performed by the memory
management unit (MMU) of modern processors. Our AnC attack
relies on the property that the MMU’s page-table walks result
in caching page-table pages in the shared last-level cache (LLC).

As a result, an attacker can derandomize virtual addresses of a
victim’s code and data by locating the cache lines that store the
page-table entries used for address translation.
Relying only on basic memory accesses allows AnC to be
implemented in JavaScript without any specific instructions or
software features. We show our JavaScript implementation can
break code and heap ASLR in two major browsers running on
the latest Linux operating system with 28 bits of entropy in 150
seconds. We further verify that the AnC attack is applicable to
every modern architecture that we tried, including Intel, ARM
and AMD. Mitigating this attack without naively disabling caches
is hard, since it targets the low-level operations of the MMU.
We conclude that ASLR is fundamentally flawed in sandboxed
environments such as JavaScript and future defenses should not
rely on randomized virtual addresses as a building block.

media.ccc.de


Intel CPU bug incoming - Something mysterious is afot
Everything from 34C3
Flaw in Intel CPU?
Intel: no benchmark for you
#2

yeah, idk if all the details on this are out yet, but its going to be extra megabad mainly for anyone that runs any kind of virtual machines for multiple customers and needs to ensure security.

It may also be bad for web browsers, but the performance penalty there will likely be negligible, even if ~30%.

I bet ryzen and TR users are feeling extra awesome right now.


#3

This is very bad. Reading into it and studying computer science at the same time, I even understand the fundamentals of the issue.
The above paragraph is just to avoid simply saying: This is very bad!

Very much so


#4

At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Pure gold.

Yes indeedy! Even more interested in VM’s now :grin:


#5

Oh god yes… my official statement to Intel users “nana boo boo you smell like doo doo”


#6

I remember seeing something about this teased a few months back.

Is the Zen core not vulnerable? I might switch some orders over to EPYC if that’s the case.


#7

nope, epyc is not vulnerable. This is an “optimization” that bit intel pretty hard.


#8

Nope, this is directly related to the clusterfuck at Intel.


#9

As far as the public knows, this specific problem has to do with the CPU “pre-fetching” instructions and executing them before performing security checks on those instructions.


#10

@noenken possible to give this an more informativ title?


#11

Damn, glad to hear it. I guess our new servers are going to be EPYC. Switching orders now.

I like the title. :smiley:


#12

I’m posting this here with the prequalifier that the full extent of this is not yet certain and it is likely to be speculative in parts.

The performance hit is also lower than most state. But in certain scenarios can be severe.

It is happening and it is of very grave concern.

https://news.ycombinator.com/item?id=16046636/


#13

#14

Now I notice that ASLR 34C3 video in my watch later list.


#15

I linked it to my 34C3 thread.

I think i’m gonna leave this till tomorrow to absorb.


#16

https://nvd.nist.gov/vuln/detail/CVE-2017-5925#vulnConfigurationsArea

NVD has some AMD FX chips listed. Interesting. Maybe we should test Zen.


#17

Pretty Epyc news, amirite?

I’m going to be livid if I feel a performance impact after the update. Bad news doesn’t even begin to explain this. It’s outrageous and downright unacceptable.


#18

I will when I get mine back from rma :neutral_face: … and hear back from asrock so I can rma my mobo too :tired_face:


#19


#20

I’m not sure who to trust here

https://lkml.org/lkml/2017/12/27/2

GrSecurity is usually not the most reputable and can be quite fuddy. Perhaps haven’t added the AMD patch.

But I also wouldn’t be surprised if this affects just about everything.