speculative execution Google and Microsoft disclosed a new CPU vulnerability named “Speculative Store Bypass” (variant 4). [update]

[captain_to_fire]

Sources: The Verge, Intel, Microsoft, Google Project Zero, US-CERT, AMD

 

Quote

Microsoft and Google are jointly disclosing a new CPU security vulnerability that’s similar to the Meltdown and Spectre flaws that were revealed earlier this year. Labelled Speculative Store Bypass (variant 4), the latest vulnerability is a similar exploit to Spectre and exploits speculative execution that modern CPUs use. Browsers like Safari, Edge, and Chrome were all patched for Meltdown earlier this year, and Intel says “these mitigations are also applicable to variant 4 and available for consumers to use today.”

 

However, unlike Meltdown (and more similar to Spectre) this new vulnerability will also include firmware updates for CPUs that could affect performance. Intel has already delivered microcode updates for Speculative Store Bypass in beta form to OEMs, and the company expects them to be more broadly available in the coming weeks. The firmware updates will set the Speculative Store Bypass protection to off-by-default, ensuring that most people won’t see negative performance impacts.

I'm no longer getting surprised with new hardware vulnerabilities which seems to be harder to patch than software vulnerabilities. It sucks that so many people might not want the patch as it will affect performance negatively but not so much unlike the variant 2 patch which bricked a lot of older computers.

 

Microsoft in their blog post discussed SSB or Speculative Store Bypass in detail.

 

https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/

Quote

Speculative Store Bypass (SSB) overview

In our blog post on mitigating speculative execution side channel hardware vulnerabilities, we described three speculation primitives that can be used to create the conditions for a speculative execution side channel. These three primitives provide the fundamental methods for entering speculative execution along a non-architectural path and consist of conditional branch misprediction, indirect branch misprediction, and exception delivery or deferral. Speculative Store Bypass (SSB) belongs to a new category of speculation primitive that we refer to as memory access misprediction.

 

SSB arises due to a CPU optimization that can allow a potentially dependent load instruction to be speculatively executed ahead of an older store. Specifically, if a load is predicted as not being dependent on a prior store, then the load can be speculatively executed before the store. If the prediction is incorrect, this can result in the load reading stale data and possibly forwarding that data onto other dependent micro-operations during speculation. This can potentially give rise to a speculative execution side channel and the disclosure of sensitive information.

 

To illustrate how this might occur, it may help to consider the following simple example. In this example, RDI and RSI are assumed to be equal to the same address on the architectural path.

01: 88040F            mov [rdi+rcx],al
02: 4C0FB6040E        movzx r8,byte [rsi+rcx]
03: 49C1E00C          shl r8,byte 0xc
04: 428B0402          mov eax,[rdx+r8]

In this example, the MOV instruction on line 1 may take additional time to execute (e.g. if the computation of the address expression for RDI+RCX is waiting on prior instructions to execute). If this occurs, the CPU may predict that the MOVZX is not dependent on the MOV and may speculatively execute it ahead of the MOV that performs the store. This can result in stale data from the memory located at RSI+RCX being loaded into R8 and fed to a dependent load on line 4. If the byte value in R8 is sensitive, then it may be observed through a side channel by leveraging a cache-based disclosure primitive such as FLUSH+RELOAD (if RDX refers to shared memory) or PRIME+PROBE. The CPU will eventually detect the misprediction and discard that state that was computed, but the data that was accessed during speculation may have created residual side effects in the cache by this point that can then be measured to infer the value that was loaded into R8.

 

This example is simplified for the purposes of explaining the issue, but it is possible to imagine generalizations of this concept that could occur. For example, it may be possible for similar sequences to exist where SSB could give rise to a speculative out-of-bounds read, type confusion, indirect branch, and so on. We have revised our C++ Developer Guidance for Speculative Execution Side Channels to include additional examples of code patterns and conditions that could give rise to an instance of CVE-2018-3639. In practice, finding an exploitable instance of CVE-2018-3639 will require an attacker to identify an instruction sequence where:

1. The sequence is reachable across a trust boundary, e.g. an attacker in user mode can trigger the sequence in kernel mode through a system call.

2. The sequence contains a load instruction that is architecturally dependent on a prior store.

3. The stale data that is read by the load instruction is sensitive and is used in a way that can create a side channel on the non-architectural path, e.g. the data feeds a disclosure gadget.

4. The store instruction does not execute before the load and the dependent instructions that compose the disclosure gadget are speculatively executed.

While our research into this new vulnerability class is ongoing, we have not identified instruction sequences that satisfy all of the above criteria and we are currently not aware of any exploitable instances of CVE-2018-3639 in our software.

 

In the case of Just-in-Time (JIT) compilers, such as JavaScript JIT employed by modern web browsers, it may be possible for an attacker to supply JavaScript that produces native code that satisfies the criteria above. However, Microsoft Edge, Internet Explorer, and other major browsers have taken steps to reduce the precision of timers to increase the difficulty of successfully creating a side channel.

Since most modern browsers use JIT compiling to be fast, looks like prioritizing speed offers significant vulnerabilities as well including malicious code making system calls which can do a lot of things. 

It reminds me with that proof of concept automated exploit tool NVIDIA and Princeton University created that leverages Spectre and Meltdown. 

It seems that when it comes to hardware vulnerabilities, tech companies will continue to play whack-a-mole. Meanwhile, I'm glad that the US-CERT didn't stockpiled this vulnerability to perpetuate their spying agenda unlike with Eternal Blue and Eternal Romance vulnerabilities. I wonder if the patch will also be disabled by default in servers and datacenters just like the microcode update for Spectre and Meltdown @leadeater.

 

Update: 

List of affected Intel CPUs: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00000.html 

 

Affected products:

The following Intel-based platforms are potentially impacted by these issues. Intel may modify this list at a later time.

    Intel® Core™ i3 processor (45nm and 32nm)
    Intel® Core™ i5 processor (45nm and 32nm)
    Intel® Core™ i7 processor (45nm and 32nm)
    Intel® Core™ M processor family (45nm and 32nm)
    2nd generation Intel® Core™ processors
    3rd generation Intel® Core™ processors
    4th generation Intel® Core™ processors
    5th generation Intel® Core™ processors
    6th generation Intel® Core™ processors
    7th generation Intel® Core™ processors
    8th generation Intel® Core™ processors
    Intel® Core™ X-series Processor Family for Intel® X99 platforms
    Intel® Core™ X-series Processor Family for Intel® X299 platforms
    Intel® Xeon® processor 3400 series
    Intel® Xeon® processor 3600 series
    Intel® Xeon® processor 5500 series
    Intel® Xeon® processor 5600 series
    Intel® Xeon® processor 6500 series
    Intel® Xeon® processor 7500 series
    Intel® Xeon® Processor E3 Family
    Intel® Xeon® Processor E3 v2 Family
    Intel® Xeon® Processor E3 v3 Family
    Intel® Xeon® Processor E3 v4 Family
    Intel® Xeon® Processor E3 v5 Family
    Intel® Xeon® Processor E3 v6 Family
    Intel® Xeon® Processor E5 Family
    Intel® Xeon® Processor E5 v2 Family
    Intel® Xeon® Processor E5 v3 Family
    Intel® Xeon® Processor E5 v4 Family
    Intel® Xeon® Processor E7 Family
    Intel® Xeon® Processor E7 v2 Family
    Intel® Xeon® Processor E7 v3 Family
    Intel® Xeon® Processor E7 v4 Family
    Intel® Xeon® Processor Scalable Family
    Intel® Atom™ Processor C Series (C3308, C3338, C3508, C3538, C3558, C3708, C3750, C3758, C3808, C3830, C3850, C3858, C3950, C3955, C3958)
    Intel® Atom™ Processor E Series
    Intel® Atom™ Processor A Series
    Intel® Atom™ Processor X Series (x5-E3930, x5-E3940, x7-E3950)
    Intel® Atom™ Processor T Series (T5500, T5700)
    Intel® Atom™ Processor Z Series
    Intel® Celeron® Processor J Series (J3355, J3455, J4005, J4105)
    Intel® Celeron® Processor N Series (N3450)
    Intel® Pentium® Processor J Series (J4205)
    Intel® Pentium® Processor N Series (N4000, N4100, N4200)
    Intel® Pentium® Processor Silver Series (J5005, N5000)

 

Quote

Most leading browser providers have recently deployed mitigations in their Managed Runtimes – mitigations that substantially increase the difficulty of exploiting side channels in a modern web browser. These techniques would likewise increase the difficulty of exploiting a side channel in a browser based on SSB.

 

Intel has released Beta microcode updates to operating system vendors, equipment manufacturers, and other ecosystem partners adding support for Speculative Store Bypass Disable (SSBD). SSBD provides additional protection by providing a means for system software to completely inhibit a Speculative Store Bypass from occurring if desired.  This is documented in whitepapers located at Intel’s Software Side-Channel Security site.    Most major operating system and hypervisors will add support for Speculative Store Bypass Disable (SSBD) starting as early as May 21, 2018.

The microcode updates will also address Rogue System Register Read (RSRR) – CVE-2018-3640 by ensuring that RDMSR instructions will not speculatively return data under certain conditions.  This is documented in whitepapers located at Intel’s Software Side-Channel Security site. No operating system or hypervisor changes are required to support the RDMSR change.

 

It is expected beta microcode updates will be fully production qualified in the coming weeks. Intel recommends end users and systems administrators check with their OEM and system software vendors and apply any available updates as soon as practical.

 

I’ll continue to update the post once AMD releases the list of their affected CPUs. 

Edited May 22, 2018 by captain_to_fire
included AMD to the sources and list of affected Intel processors

[hconverse02]

Huh

[bellabichon]

Yaaaaay. Year of the hackers, and the bitcoin miners. 

[captain_to_fire]

1 minute ago, bellabichon said:

Yaaaaay. Year of the hackers, and the bitcoin miners. 

Most cryptojacking attacks (attacks that inject cryptominers without consent) are prevented by most antivirus programs

[Ginger_]

Aww screw this. I mean, I'm glad people are finding these before malicious hackers, but I hate seeing processing power pissed away to hot patch a problem every few months when a new flaw is discovered

[bellabichon]

1 hour ago, captain_to_fire said:

Most cryptojacking attacks (attacks that inject cryptominers without consent) are prevented by most antivirus programs

That's not what I was talking about. I was just saying that 2017-2018 has been a year of ups and downs for the PC gaming community. Sure, we had the 'revival' of AMD, but GPU prices and the CPU Kernel attacks have sucked. 

[Jurrunio]

The previous patch for Spectre and Meltdown already took 10% of my Cinebench score with it. I really dont want another 10% off...

[leadeater]

34 minutes ago, captain_to_fire said:

I wonder if the patch will also be disabled by default in servers and datacenters just like the microcode update for Spectre and Meltdown @leadeater.

Argh!! Too many flaws with the same freakin name, so confusing. Can we just fix the first ones properly before moving on to new ones.

 

[Ashleyyyy]

will this affect older cpu's more than newer one's? if so i'm screwed.. 

[AnonymousGuy]

Honestly at this point it reads like a bunch of PHD students trying to find hyper obscure corner case vulnerabilities that will never actually be exploitable in the wild.

[leadeater]

@captain_to_fire There's actually two newly announced vulnerabilities btw, "Rogue System Register Read"

 

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180013

 

ADV180012 is the one for this thread fyi. Microsoft email about it came in this morning.

[Drak3]

7 minutes ago, leadeater said:

Too many flaws with the same freakin name, so confusing.

Would you say it's more or less confusing than the GTX 1050, GTX 1050, and GTX 1050?

 

Spoiler

2GB, mobile, 3GB

 

[Kamina]

Technology just sucks as of late.

[leadeater]

5 hours ago, Drak3 said:

Would you say it's more or less confusing than the GTX 1050, GTX 1050, and GTX 1050?

 

  Reveal hidden contents

2GB, mobile, 3GB

 

Currently more, extremely hard to figure out exactly what you are patched for and what you are not patched for right now and to top if off to what extent because you can be patched but not fully patched i.e. CPU microcode.

 

I might be playing dumb but regardless it is a right pain in the ass that these are all 'variants' of the same thing which makes it exceedingly hard to explain to other people and what the actual risks are. "But didn't we already patch Spectre?", "Yes but....".

[Drak3]

1 minute ago, leadeater said:

Currently more, extremely hard to figure out exactly what you are patched for and what you are not patched for right now and to top if off to what extent because you can be patched but not fully patched i.e. CPU microcode.

 

I might be playing dumb but regardless it is a right pain in the ass that theses are all 'variants' of the same thing which makes it exceedingly hard to explain to other people and what the actual risks are. "But didn't we already patch Spectre?", "Yes but....".

Ah, so more confusing than the Razer:

 

BlackWidow Chroma

BlackWidow Chroma

BlackWidow Chroma

BlackWidow Chroma

And BlackWidow Chroma.

[leadeater]

2 minutes ago, Drak3 said:

Ah, so more confusing than the Razer:

 

BlackWidow Chroma

BlackWidow Chroma

BlackWidow Chroma

BlackWidow Chroma

And BlackWidow Chroma.

I find the keys on those keyboards have a bit too stronger bite to them.

 

Spoiler

 

[ARikozuM]

3 minutes ago, leadeater said:

I find the keys on those keyboards have a bit too stronger bite to them.

 

  Reveal hidden contents

 

Nah, it’s just the RGB fooling you.

 

Also, someone should make a black widow where the hourglass is RGB.

[ARikozuM]

Intel is probably kicking itself for not driving higher performance for the last eight years. 

[Misanthrope]

There's mention of intel patching but no AMD: Is AMD not responding, not expected to be vulnerable, what's their status?

[Ashleyyyy]

4 minutes ago, ARikozuM said:

Intel is probably kicking itself for not driving higher performance for the last eight years. 

probably.. 

 

16 minutes ago, Kamina said:

Technology just sucks as of late.

very true. 

[Zodiark1593]

9 minutes ago, ARikozuM said:

Intel is probably kicking itself for not driving higher performance for the last eight years. 

By the looks of it, these vulnerabilities may hamstring a lot of potential avenues for improvements, clock speeds aside.

 

22 minutes ago, leadeater said:

Currently more, extremely hard to figure out exactly what you are patched for and what you are not patched for right now and to top if off to what extent because you can be patched but not fully patched i.e. CPU microcode.

 

I might be playing dumb but regardless it is a right pain in the ass that theses are all 'variants' of the same thing which makes it exceedingly hard to explain to other people and what the actual risks are. "But didn't we already patch Spectre?", "Yes but....".

It's likely the patches don't fix the vulnerabilities at the root (which could very well incur heavy performance hits), but rather, specific and likely ways the exploit can be used. So long as the root of the exploit isn't addressed, the "Whack-A-Mole" continues onward. 

 

In the article detailing the Spectre vulnerability, it was warned that this particular exploit would be "haunting us for some time". I hypothesize that this was what was meant.

[Rune]

Quote

The firmware updates will set the Speculative Store Bypass protection to off-by-default, ensuring that most people won’t see negative performance impacts.

.....why develop the fix if it is going to be set to off by default?

[captain_to_fire]

1 hour ago, leadeater said:

Argh!! Too many flaws with the same freakin name, so confusing. Can we just fix the first ones properly before moving on to new ones.

Variant 1 & 2 - Spectre

Variant 3 - Meltdown

Variant 4 - Speculative Store Bypass

 

I bet by the end of 2018 we'll be informed by a variant 10 vulnerability which also takes advantage of speculative execution 

1 hour ago, firelighter487 said:

will this affect older cpu's more than newer one's? if so i'm screwed.. 

The better question would be "will older CPUs receive the microcode update?'

1 hour ago, leadeater said:

@captain_to_fire There's actually two newly announced vulnerabilities btw, "Rogue System Register Read"

 

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180013

 

ADV180012 is the one for this thread fyi. Microsoft email about it came in this morning.

An attacker who has successfully exploited this vulnerability could then bypass Kernel Address Space Layout Randomization (KASLR) protections. To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application. The mitigation for this vulnerability is exclusively through a microcode/firmware update, and there is no additional Microsoft Windows operating system update.

 

Welp! Good thing all it needs is a software update and no microcode updates required

42 minutes ago, Misanthrope said:

There's mention of intel patching but no AMD: Is AMD not responding, not expected to be vulnerable, what's their status?

Unfortunately, I was possessed by zMeul's spirit when making the OP to not include AMD 

/s 

 

updated the OP sources https://www.amd.com/en/corporate/security-updates

Quote

“Speculative Store Bypass” Vulnerability Mitigations for AMD Platforms

5/21/18

Today, Microsoft and Google Project Zero researchers have identified a new category of speculative execution side channel vulnerability (Speculative Store Bypass or SSB) that is closely related to the previously disclosed GPZ/Spectre variant 1 vulnerabilities.  Microsoft has released an advisory on the vulnerability and mitigation plans. 

 

AMD recommended mitigations for SSB are being provided by operating system updates back to the Family 15 processors (“Bulldozer” products). For technical details, please see the AMD whitepaper. Microsoft is completing final testing and validation of AMD-specific updates for Windows client and server operating systems, which are expected to be released through their standard update process.  Similarly, Linux distributors are developing operating system updates for SSB. AMD recommends checking with your OS provider for specific guidance on schedules.

Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.

We have not identified any AMD x86 products susceptible to the Variant 3a vulnerability in our analysis to-date.

 

As a reminder, security best practices of keeping your operating system and BIOS up-to-date, utilizing safe computer practices and running antivirus software are always the first line of defense in maintaining device security.

But hey at least it's not a smear campaign like the shady CTS labs

[captain_to_fire]

1 hour ago, Ginger_ said:

Aww screw this. I mean, I'm glad people are finding these before malicious hackers, but I hate seeing processing power pissed away to hot patch a problem every few months when a new flaw is discovered

I wonder why no one has done a YouTube video comparing pre and post microcode updates like video editing and exporting, gaming, thermal throttling, etc. Maybe Linus can do it?

[Arika]

we've made CPUs too complex...