Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

[VirtualLarry]

Wow. I stand corrected. I did not know it was possible to do...

I should buy more AMD shares...

The mov-only DOOM renders approximately one frame every 7 hours, so playing this version requires somewhat increased patience.

Well, that technique isn't exactly perfect, if you need computations in real-time.

 

[maddie]

Well, that technique isn't exactly perfect, if you need computations in real-time.

Too serious here. That link was a hilarious comic irony.

 

[HurleyBird]

Is this for real? They are literally recommending not to use if statement. WTF.

It sounds more like this:

if (x < 0) x = 0;

is affected, rather than:

if (x < 0) y = 0;

At least that's the way I read it. Could be wrong. But even if I'm right, that's... still really bad.

 

[Hitman928]

Update from Toms. AMD confirms their CPUs are not effected by Spoiler. They also say that Cofee Lake and upcoming Intel CPUs are still vulnerable.

https://www.tomshardware.com/news/amd-processor-intel-spoiler-vulnerability,38841.html

Today AMD responded to news of the Spoiler vulnerability by confirming that its processors are not vulnerable to the exploit

The Spoiler exploit is present specifically within Intel's Core CPUs, which include the original Core 2 Duo CPUs all the way up to Intel's most recent Coffee Lake, Kaby Lake, and Skylake CPUs, as well as future Cascade Lake and Ice Lake products.

 

[DrMrLordX]

IceLake huh?

Woops.

 

[Tuna-Fish]

Is this for real? They are literally recommending not to use if statement. WTF.

Yes. And this advice will be permanent, btw. Spectre 1 is the only one of these new vulns that cannot be fixed without throwing away almost all of the performance of modern CPUs.

And the scope isn't if statements in general, it's specifically using control flow alone to guard data that is not supposed to be accessible. A good example of this would be the javascript engine in browsers doing a boundary check on array access. Traditionally, this might be something like:

int checked_get(size_t len, size_t index, int *array){
    if (index < len) return array[index];
    //if index > len, and that is rare in the program, the wrong value past the end of the array is speculatively returned.
    //since this was supposed to prevent a javascript program accessing things like cryptographical keys that can reside
    //in the same address space, this is a problem.

    //something else to deal with overflow
}

In the brave new world, this is not safe, and cannot be made safe by changes to cpus alone. Note that if statements are not the only flow control that is affected, things like Liskov substitution has also been successfully attacked. (That is, using multiple different subclasses of a superclass with different implementations, and leaking information by tricking the cpu to speculatively use the wrong subclass on the data of a different subclass.)

In the future, to protect data that is not supposed to be available, you need to use arithmetic or non-control-flow logic operations. Modifying our earlier example:

int checked_get(size_t len, size_t index, int *array){
    //make bitmask. works if len is a power of two
    size_t mask = len + len -1;
    if (index < len) return array[index & mask];
   // this way, if index is greater than len, it will speculatively return the wrong value but from inside the values you could access anyway.
   // no protection boundary is violated.

    //something else to deal with overflow
}

In principle, this was one of the transformations that was actually done to make javascript safe again.

In future, this might mean we will get things like new, fast boundary checking instructions that do the above (or something else safe) that can be used instead. Even a fast scalar max() implemented as a single-cycle instruction that depended on both values and outputted the larger one would do the trick. But the primary problem, that you can leak data from speculative contexts using the cache, and that control flow is no longer a safe way to enforce protection boundaries, cannot and will not be fixed, and affects all fast CPUs going forward.

 

[moinmoin]

But the primary problem, that you can leak data from speculative contexts using the cache, and that control flow is no longer a safe way to enforce protection boundaries, cannot and will not be fixed, and affects all fast CPUs going forward.

You state this as something universally true. Is it? What's included as a "fast CPU" in this context, e.g. all modern ARM cores as well? Anything with any form of speculative execution?

 

[Tuna-Fish]

You state this as something universally true. Is it? What's included as a "fast CPU" in this context, e.g. all modern ARM cores as well? Anything with any form of speculative execution?

Basically everything that combines branch prediction and a cache. This includes all the fast arm cores.

 

[amd6502]

The existential crisis for modern CPUs (not just x86) continues. This latest one in the news is x86 specific though towards core series. I don't know anything about it. If anyone is up for it, it looks like some very deep reading that's going to take a chunk of time https://arxiv.org/pdf/1903.00446.pdf . https://www.guru3d.com/news-story/intel-procs-again-hit-by-massive-vulnerability-called-spoler.html

 

[Tuna-Fish]

The existential crisis for modern CPUs (not just x86) continues. This latest one in the news is x86 specific though towards core series. I don't know anything about it. If anyone is up for it, it looks like some very deep reading that's going to take a chunk of time https://arxiv.org/pdf/1903.00446.pdf . https://www.guru3d.com/news-story/intel-procs-again-hit-by-massive-vulnerability-called-spoler.html

That one has been discussed on this thread since March 5th.

 

[amd6502]

That one has been discussed on this thread since March 5th.

I'm new to this one; from browsing the article for 90 minutes but not really understanding most the details, it doesn't seem too bad in itself. It seems like it would take a very large amount of work to make practical real life use of it. The snooping on timings almost universal in the unpatched exploits. Webassembly seems like a bad idea that's going to be exploited very badly anyways.

My take is web apps will just have to be trusted to do a good job on security, and sandbox javascript as best as they can with timer functions that output with increasing noise for scripts that make excessive frequent calls.

 

[jpiniero]

https://www.phoronix.com/scan.php?page=article&item=intel-cascadelake-linux&num=6

Looks like the hardware mitigations in Cascade Lake are actual mitigations and not just microcode, as evidenced by the context switch benchmark.

 

[UsandThem]

Yet another variation / vulnerability:

https://www.zdnet.com/article/intel-cpus-impacted-by-new-zombieload-side-channel-attack/

Today, an international team of academics -- including some of the people involved in the original Meltdown and Spectre research -- along with security researchers from Bitdefender have disclosed a new attack impacting the speculative execution process.

This one is what researchers have named a Microarchitectural Data Sampling (MDS) attack, and targets a CPU's microarchitectural data structures, such as the load, store, and line fill buffers, which the CPU uses for fast reads/writes of data being processed inside the CPU. These are smaller-sized caches that are used alongside the main CPU cache.

 

[Hitman928]

Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.

Furthermore, newer processors aren't impacted, as they already include protections against speculative execution attacks --such as the MDS attacks-- since last year when Meltdown and Spectre first hit, and Intel modified the way its CPU's worked.

Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.

 

[amdfan111]

In a call with TechCrunch, Intel said the microcode updates, like previous patches, would have an impact on processor performance. An Intel spokesperson told TechCrunch that most patched consumer devices could take a 3 percent performance hit at worst, and as much as 9 percent in a datacenter environment. But, the spokesperson said, it was unlikely to be noticeable in most scenarious.

Yet again, AMD not affected, but sure, 9% performance decrease will surely not be "noticeable." Ryzen was tied with Intel at launch, and now between Meltdown, Spectre, L1TF, and this new Zombie(!) exploit, Ryzen is 30% higher IPC than Coffee or whatever Lake.

 

[Hitman928]

Toms reporting that intel is recommending turning off hyperthreading altogether to avoid issues:

in its paper, the company [intel] stated that disabling HT altogether may be warranted as protection against MDS attacks.

https://www.tomshardware.com/news/intel-disable-hyper-threading-spectre-attack,39333.html

 

[Fanatical Meat]

Toms reporting that intel is recommending turning off hyperthreading altogether to avoid issues:



https://www.tomshardware.com/news/intel-disable-hyper-threading-spectre-attack,39333.html

Be fair and include this:

Intel clarified that it's not recommending everyone to disable Hyper-Threading, but that some of its customers should consider the option depending on their security needs:

 

[Deigarth]

Turning off HT doesn't stop ZombieLoad though.

https://www.cyberus-technology.de/posts/2019-05-14-zombieload.html

Even without Hyperthreading, it is possible to leak data out of other protection domains. During experimentation it turned out, that ZombieLoad leaks endure serializing instructions. Such leaks do however work with lower probability and are harder to obtain.

 

[DrMrLordX]

Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.

Just another reason for people to get off those Skylake-SP systems. It'll be interesting to see what they buy as replacements.

Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.

I know, right? People are so touchy sometimes.

 

[Deigarth]

It also looks like Intel abused the process of responsible disclosure for economic reasons. Wasting security researchers time, trying to "gift" them money instead of a proper bug bounty and also trying to delay release to the public. It think it reflects badly on them, security researchers will probably not put up with that again.

Wired:

That's hardly the kind of money paid out for trivial issues, he points out. But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws. VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.

Translated from the NL interview:

The VU tried to force the manufacturer to come out faster. Eventually the VU forced Intel to come out in May - otherwise the university would publish the details itself. "If it were up to Intel, they would have wanted to wait another six months," says Bos.

Sources:
https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/
https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

Edit:

https://twitter.com/x/status/1128394656922972160

 

[Hans de Vries]

Looks like the new architecture changes cover this new attack. Older CPUs have received / will receive microcode updates.

Edit: I'm just quoting the zdnet article. If you disagree with it, take it up with them, not me, lol.

It seems to get only worse instead: https://mdsattacks.com/

 

[TheGiant]

ok, so we get another patches and whatever.....

Intel has like 90+% of CPUs used in the computer world, it is logical the researchers focused on them

any info if researchers plan to exploit EPYCs, power, apple axx etc CPUs?

they work by logical algoritms all, so can be broken...

 

[jpiniero]

I wouldn't be surprised if the bribing they are talking about was so that they can move the remaining stock of Skylake-SP, assuming Cascade Lake is unaffected.

It seems to get only worse instead: https://mdsattacks.com/

That's the confusing thing about this. Are they talking about the microcode changes Intel's done so far or the hardware fixes?

 

[DrMrLordX]

It seems to get only worse instead:

Ugh. More vulnerable? Is there any more data on that?

That's the confusing thing about this. Are they talking about the microcode changes Intel's done so far or the hardware fixes?

The main difference between 8th and 9th gen chips is the hardware mitigations (wrt Spectre/Meltdown). So the hardware mitigations may introduce new flaws.

 

[Hitman928]

It seems to get only worse instead: https://mdsattacks.com/

View attachment 6339

Seems like Intel's whitepaper and the actual security researchers are not on the same page for this vulnerability. That's really not a good look for intel.