New 'CacheOut' attack targets Intel processors, with a fix arriving soon

[RejZoR]

9 hours ago, Arika S said:

I'm curious to see how many security firms are looking into both companies products. It could be as simple as ryzeb being fairly new any therefore less people looking for vulnerabilities or they just haven't found them yet. 

I doubt that's the case. If anything, poking Ryzen CPU's would be very lucrative business since it's new and can potentially be full of holes. It would be weird that Intel architecture goes back for years, but somehow just now they found all the holes in a span of what, 2 years?

[mr moose]

16 minutes ago, RejZoR said:

I doubt that's the case. If anything, poking Ryzen CPU's would be very lucrative business since it's new and can potentially be full of holes.

But Ryzens have no where near the market share,  especially in business where the money is.   Same reason viruses are targeted at the most used OS's.

 

16 minutes ago, RejZoR said:

It would be weird that Intel architecture goes back for years, but somehow just now they found all the holes in a span of what, 2 years?

It goes back decades, and the holes they have found are holes that are pertinent to decades old technology.   I believe the technology used in Intel CPU's that most side channel attacks a founded on  came out in 2002. 

[leadeater]

32 minutes ago, RejZoR said:

I doubt that's the case. If anything, poking Ryzen CPU's would be very lucrative business since it's new and can potentially be full of holes. It would be weird that Intel architecture goes back for years, but somehow just now they found all the holes in a span of what, 2 years?

We have way better tools for finding exploits and non standard behavior, it's the side effect of the rise of ML and AI.

[Kisai]

11 hours ago, TempestCatto said:

I have a very serious question: how the fuck does this keep happening to Intel and not AMD? As if their luck couldn't get any worse - what with AMD actually pumping out hella good CPU's. Hopefully next gen Intel will solve at least most of these.

Because security was never a point considered by the Intel chip designers, not until 2018 at least. For the first time since the return to Pentium 3 architecture after abandoning NetBurst, we see newer chips with no performance gains.

 

 

Instead the gains are on adding more cores, which would be fine if any software really was designed to use multi-cores. Now it's proving that the short cuts taken with multi-cores are where the security flaws are coming from, shared caches and other cpu logic which should never be shared.

 

 

[mr moose]

11 minutes ago, Kisai said:

Because security was never a point considered by the Intel chip designers,

This is a pretty big claim.

[Kisai]

10 minutes ago, mr moose said:

This is a pretty big claim.

Would you rather I have said "Intel engineers just ignored obvious security issues because they needed to ship something by a deadline" ?

 

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

https://en.wikipedia.org/wiki/Pentium_F00F_bug

 

https://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly

 

https://forums.intel.com/s/question/0D50P0000490FYeSAM/simple-instructions-for-freezing-a-skylake-processor?language=en_US&start=15&tstart=0

 

Quote

As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

Why?

Let me set the scene: It's late in 2013. Intel is frantic about losing the mobile CPU wars to ARM. Meetings with all the validation groups. Head honcho in charge of Validation says something to the effect of: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times... we can't live forever in the shadow of the early 90's FDIV bug, we need to move on. Our competition is moving much faster than we are" - I'm paraphrasing. Many of the engineers in the room could remember the FDIV bug and the ensuing problems caused for Intel 20 years prior. Many of us were aghast that someone highly placed would suggest we needed to cut corners in validation - that wasn't explicitly said, of course, but that was the implicit message. That meeting there in late 2013 signaled a sea change at Intel to many of us who were there. And it didn't seem like it was going to be a good kind of sea change. Some of us chose to get out while the getting was good. As someone who worked in an Intel Validation group for SOCs until mid-2014 or so I can tell you, yes, you will see more CPU bugs from Intel than you have in the past from the post-FDIV-bug era until recently.

https://danluu.com/cpu-bugs/

[mr moose]

6 minutes ago, Kisai said:

Would you rather I have said "Intel engineers just ignored obvious security issues because they needed to ship something by a deadline" ?

 

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

https://en.wikipedia.org/wiki/Pentium_F00F_bug

 

https://www.anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwelly

 

https://forums.intel.com/s/question/0D50P0000490FYeSAM/simple-instructions-for-freezing-a-skylake-processor?language=en_US&start=15&tstart=0

 

https://danluu.com/cpu-bugs/

Yeah, I'm going to go ahead and say that having a few bugs and faulty products like that over 25Years is not the exactly same as not paying any attention to security.  Also Taking the word of randoms on reddit is not going to convince me of much, especially if their prediction was for us to see "lots" more bugs over the next few years(from 2015) and we have seen what?  half a dozen over the last 5 years ( most of which they already knew existed prior to those comments and just couldn't provide proof of exploit yet).  I mean, I could claim that we will encounter a few bugs over the next few years in AMD products and then look back in 5 years and have enough happened to claim I was right.

 

What I see is a very complex product that has evolved over 30 years in a very competitive market by 10ooo's of different engineers.  Of course things are going to go wrong.  This doesn't mean any of it was intentional

[porina]

I poked around a bit more. It is interesting that Intel only lists Skylake and newer CPUs in the affected list. Haswell and earlier are listed as not affected, so at least anyone running an older Intel system can ignore this one. So whatever it is, it was introduced in Skylake, which has been the foundation for most CPUs since. I didn't check if Atom class CPUs or Sunny Cove were affected or not.

[RejZoR]

4 minutes ago, porina said:

I poked around a bit more. It is interesting that Intel only lists Skylake and newer CPUs in the affected list. Haswell and earlier are listed as not affected, so at least anyone running an older Intel system can ignore this one. So whatever it is, it was introduced in Skylake, which has been the foundation for most CPUs since. I didn't check if Atom class CPUs or Sunny Cove were affected or not.

It might be SGX dependent. Coz only Skylake and newer have SGX functionality. My Haswell-E doesn't have it. Great news *in James May voice*

[leadeater]

1 hour ago, RejZoR said:

Great news *in James May voice*

 

Holding on to my computer until it's completely useless is starting to pay off.

[Kisai]

1 hour ago, mr moose said:

Yeah, I'm going to go ahead and say that having a few bugs and faulty products like that over 25Years is not the exactly same as not paying any attention to security.  Also Taking the word of randoms on reddit is not going to convince me of much, especially if their prediction was for us to see "lots" more bugs over the next few years(from 2015) and we have seen what?  half a dozen over the last 5 years ( most of which they already knew existed prior to those comments and just couldn't provide proof of exploit yet).  I mean, I could claim that we will encounter a few bugs over the next few years in AMD products and then look back in 5 years and have enough happened to claim I was right.

 

What I see is a very complex product that has evolved over 30 years in a very competitive market by 10ooo's of different engineers.  Of course things are going to go wrong.  This doesn't mean any of it was intentional

If you notice, I was pointing to how the FDIV bug was the reason why Intel products were being over-engineered and then something around Haswell (2014) changed and now there are critical bugs being missed in validation, and it appears the entire design of the chip since Skylake has been something of insufficient validation.

 

These bugs didn't come out of thin air.

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf

116 bugs, 0 fixed.

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf

173 bugs, 0 fixed.

 

https://cdrdv2.intel.com/v1/dl/getcontent/332689

188 bugs in Skylake, 0 fixed.

 

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/7th-gen-core-family-spec-update.pdf

 

There are 145 bugs in the 7th Generation and Kaby-Lake-R chips. Only 18 are "fixed".

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/8th-gen-core-spec-update.pdf

 

137 bugs, only 7 fixed.

 

 

[porina]

1 hour ago, RejZoR said:

It might be SGX dependent. Coz only Skylake and newer have SGX functionality. My Haswell-E doesn't have it. Great news *in James May voice*

Now I had time to look more, it does mention SGX on the vulnerability site. Also looking more at the affected CPU list, Atom and Knight series (Xeon Phi) are also not affected. Ice Lake (Sunny Cove) was not mentioned at all.

[Sauron]

16 hours ago, TempestCatto said:

I have a very serious question: how the fuck does this keep happening to Intel and not AMD? As if their luck couldn't get any worse - what with AMD actually pumping out hella good CPU's. Hopefully next gen Intel will solve at least most of these.

I think at least some of it has to do with how widespread Intel infrastructure is - more people pentesting means more CVEs, regardless of how well the product was designed.

 

The other reason is that now the cat is out of the bag with speculative execution. Researchers know that it's likely there are more exploits to be found on that path so they can focus their efforts on a smaller surface. One could argue this is just a single hardware vulnerability, it's just that more ways of exploiting it are being found. It's also particularly unfortunate because speculative execution has remained virtually unchanged for over a decade while other potentially vulnerable features have been changed over time.

15 hours ago, spartaman64 said:

Idk if that's an excuse anymore with the large amount of market share amd carved out. I think Intel just cut a lot of corners to get more performance 

We're talking about cloud infrastructure here so yes, it's still a pretty valid excuse. It takes years for data centers to migrate to a new platform and pentesters need some time to get used to the new technology anyway.

[TechyBen]

10 hours ago, mr moose said:

Like many of the latest exploits, they need local access, however what actually defines local access is becoming hotly debated. 

For cloud based servers, this is bad. As it generally means anyone renting space on a multi user server, can dump memory/data from other users. For home users, it only becomes a risk when remote (HTML/JAVA sites) or local (virus/worm/etc escalation, or installed software/malware) exploits use it.

(from what I've come to understand. There were some good Spectre talks on Youtube from the smaller providers as they were more open, though due to the big providers locking them out of security fix updates)

 

And also, for all those saying "it's just AMD has a smaller market share". Well, no. Intel specifically use a lot more speculative compute architecture. It is/was more risky by nature. It may be AMD has the same number of *hidden* risks. But Intel has the easier to exploit, due to the type of CPU design.

 

It might change in 10 years if we discover a Chiplet exploit (possible IMO, as it IS a shared bus ). But that depends how/if AMD is ring fencing regions/nodes and if/how timing/power draw channel attacks are easy/hard to exploit.

 

All CPUs can be exploited via power channel attacks, but at current known methods, it'd take a decade or two, or need specialist local knowledge (know the power feed into the PC, the exact binning of the CPU etc) to exploit, so not worth it. But the proof of concepts are rather interesting:

 

[Mira Yurizaki]

2 hours ago, Tony Tony Chopper said:

Intel puts performance before security unlike AMD who prioritizes security

Is there any actual proof to AMD prioritizing security? Just because they aren't affected by one exploit doesn't mean they have another. This is like saying macOS has no security issues because none of the viruses that target Windows affects them.

[cj09beira]

18 hours ago, TempestCatto said:

I have a very serious question: how the fuck does this keep happening to Intel and not AMD? As if their luck couldn't get any worse - what with AMD actually pumping out hella good CPU's. Hopefully next gen Intel will solve at least most of these.

it all points to amd having put a large amount of effort into having a secure cpu, just look at the security features zen has added, it was high in their priority list.

 

look at the amount of attack vectors found recently, the research industry has exploded and it seems like there is much more people looking for attack vectors than before, and researchers like this can easily see that amd is strong right now, we even saw that research group go just after amd and they found nothing important (the vector found needed very early bios to work and physical access), doesnt seem like it took 10 years to exploit, but more like now there is much more interest in exploiting it than before

[cj09beira]

Just now, Mira Yurizaki said:

Is there any actual proof to AMD prioritizing security? Just because they aren't affected by one exploit doesn't mean they have another. This is like saying macOS has no security issues because none of the viruses that target Windows affects them.

amd themselves have said as much many times, and they are pioneering things like full ram encryption, with each vm having a different encrypted "password", you dont see that kind of security feature being worked on at intel

[Mira Yurizaki]

32 minutes ago, cj09beira said:

amd themselves have said as much many times, and they are pioneering things like full ram encryption, with each vm having a different encrypted "password", you dont see that kind of security feature being worked on at intel

That's more of an end-user facing feature. I'm thinking more about "we're making sure our processors don't have exploits to the best of our abilities"

 

The encryption part is kind of useless if you can successfully attack it.

 

EDIT: Also I'm more concerned about security in the actual CPU cores themselves. These exploits target flaws in the CPU architecture. So it doesn't matter if your RAM is encrypted, the data is decoded in the CPU and anything that can attack the caches and dump data from them is a problem.

Edited January 28, 2020 by Mira Yurizaki

[pas008]

18 hours ago, Morgan MLGman said:

Remember that AMD is also less targeted, because it is less-widely used.

do they officially have a bug bounty program?

[TechyBen]

1 hour ago, Mira Yurizaki said:

Is there any actual proof to AMD prioritizing security? Just because they aren't affected by one exploit doesn't mean they have another. This is like saying macOS has no security issues because none of the viruses that target Windows affects them.

MacOS though, unlike windows, might have specific security systems that Windows does not as standard. Dropping 32 bit, no unauthorised drivers, etc, as an example. Same here with Intel vs AMD. We are saying, a motorbike is inherently less stable than a car. Not motorbikes are worse than cars, just different. Intel was different... when it came to security.

[Mira Yurizaki]

5 minutes ago, TechyBen said:

Same here with Intel vs AMD. We are saying, a motorbike is inherently less stable than a car. Not motorbikes are worse than cars, just different. Intel was different... when it came to security.

I'm aware of that.

 

I'm annoyed people think that because things only seemingly affect Intel or we know more about security issues on Intel CPUs, AMD is more secure by default. Because going by that logic, that more known exploits = less secure, Linux is the worst OS since it has the most CVEs out of any other OS on their list.

 

Who knows? Maybe in another 10 years when AMD has gotten enough traction and people poke at it more, we'll start finding issues with their platforms.

[leadeater]

1 hour ago, Mira Yurizaki said:

I'm annoyed people think that because things only seemingly affect Intel or we know more about security issues on Intel CPUs, AMD is more secure by default. Because going by that logic, that more known exploits = less secure, Linux is the worst OS since it has the most CVEs out of any other OS on their list.

 

Who knows? Maybe in another 10 years when AMD has gotten enough traction and people poke at it more, we'll start finding issues with their platforms.

When AMD first launched the Zen architecture they stated security was a large priority during the design and there were a lot of choices made to keep caches secure and proper thread isolation. It's something any company would do given the chance for a complete ground up new architecture plus AMD needed every advantage they could get to effectively compete.

 

Outside of the cores and caches on the EPYC product line SEV and the security chip was also to make it as attractive as possible to VM host providers.

 

Thing is situation the same Intel would also approach it exactly the same way, but they have yet to do a ground up change.

[Mira Yurizaki]

22 minutes ago, leadeater said:

When AMD first launched the Zen architecture they stated security was a large priority during the design and there were a lot of choices made to keep caches secure and proper thread isolation.

This doesn't really answer any lingering questions I have. There's nothing I can glean from what the mainstream channels have said about it that can identify why AMD's choices were better in the long run, or what they even did. In fact, a major concern still is how blackbox AMD's secure enclave is (https://libreboot.org/amd-libre.html)

 

22 minutes ago, leadeater said:

Outside of the cores and caches on the EPYC product line SEV and the security chip was also to make it as attractive as possible to VM host providers.

 

Thing is situation the same Intel would also approach it exactly the same way, but they have yet to do a ground up change.

I would argue the problem with Intel as a platform is that when you buy their CPU, all you're getting is a CPU, a PCIe controller, and maybe a GPU with the associated hardware. Everything else about Intel's platforms appears modular. Like AMD's secure enclave is built into the processor, but Intel platforms require the use of an external module. So this leaves it open for plenty of MITM attacks.

 

In any case, I did find a post that attempts to explain why Intel designed their processors the way they did (emphasis was not added):

Quote

Until Meltdown / Spectre, CPU designers were only worried about making sure memory protection applied to the architectural state (non-speculative values in architectural registers, not physical registers used by out-of-order execution). i.e. this side-channel wasn't on anyone's radar. The results of instruction execution don't become architectural state until retirement, so that's the point when everything has to be correct (in pre-Meltdown thinking).

 

As a CPU designer, you want everything to execute as efficiently as possible, with as few special cases as possible. Or especially, with special cases in as few components as possible. It's simpler for the overall design if an execution unit can never stall, so that a pipelined section of logic doesn't need any flow-control, just simply always accept one new input per clock.

 

...

 

Most code doesn't page-fault by trying to load from kernel addresses, so optimizing for that case wasn't a consideration. If such loads are seen by out-of-order execution, they usually happen as a result of mis-speculation (running a load instruction with the wrong data in register). (Not necessarily maliciously induced mis-speculation (Spectre), just the regular kind from imperfect branch prediction.) Not doing anything about a TLB-hit faulting load until retirement is a good design decision if most of the time it never reaches retirement because a branch mispredict or other mis-speculation is detected earlier in in-order retirement. Wasting load bandwidth and causing cache pollution is questionable, but (other than Meltdown attacks) this is probably a pretty rare case so keeping the hardware simple was the most valuable thing.

You can be angry all you want that Intel did basically go "we won't consider this extreme corner case for performance reasons," but hindsight is 20/20 and it's easy to be an expert after the fact.

[leadeater]

33 minutes ago, Mira Yurizaki said:

Like AMD's secure enclave is built into the processor

Intel does actually have the problems you point to in their CPUs, IME for example. Intel CPUs haven't been the way you described them for as along as the core architecture has existed, I don't remember enough about Pentium 4 era anymore to say if it spans back to that as well. AMD PSP is the equivalent of IME. IME being in the PCH instead of the CPU doesn't make any piratical difference to the security implication you're alluding to because unless Intel changes their business model the chipsets are tied to the generation of the CPU and also only they make chipsets for their processors. You're not going to get an IME hardware fix without a new release of a chipset generation which comes with a new CPU generation, the only 'fix' for current affected hardware is to put in non functioning IME firmware (more correctly less functioning). You can likely do the same for Zen if that is ever required.

 

Quote

This includes source code for all initialization firmware (typically referred to as the BIOS or UEFI firmware, by some members of the community), and in particular, the AMD Platform Security Processor, to allow the free/libre software community to use AMD hardware that is entirely freedom-respecting. If it’s not too much to ask, we also would like source code and signing keys, including for the PSP and microcode for the CPU.

The problem is that can be too much to ask for, this is AMD's IP after all and handing that over does more than just what they want it for, not security related. I can't make that call and neither can Libre, they can ask but them asking doesn't make this statement true. Have to watch out for instances of idealism being put before realism. This is abig area AMD has a competitive advantage over Intel and they are asking for all the source code for it, data sheets and design guides, I'm sure AMD is very willing to not do that.

 

This is some of the unique security features from AMD for EPYC, Intel doesn't have equivalents at all but there are software options.

Quote

Zen added support for AMD's Secure Memory Encryption (SME) and AMD's Secure Encrypted Virtualization (SEV). Secure Memory Encryption is real-time memory encryption done per page table entry. Encryption occurs on a hardware AES engine and keys are managed by the onboard "Security" Processor (ARM Cortex-A5) at boot time to encrypt each page, allowing any DDR4 memory (including non-volatile varieties) to be encrypted. AMD SME also makes the contents of the memory more resistant to memory snooping and cold boot attacks.[70][71]

“

SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is marked encrypted will be automatically decrypted when read from DRAM and will be automatically encrypted when written to DRAM. The SME feature is identified through a CPUID function and enabled through the SYSCFG MSR. Once enabled, page table entries will determine how the memory is accessed. If a page table entry has the memory encryption mask set, then that memory will be accessed as encrypted memory. The memory encryption mask (as well as other related information) is determined from settings returned through the same CPUID function that identifies the presence of the feature.

”

[72]

The Secure Encrypted Virtualization (SEV) feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high-performance encryption engine which can be programmed with multiple keys for use by different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes an API for these tasks.[73]

 

Quote

Secure Memory Encryption (SME) is a new feature which offers full hardware memory encryption against physical memory attacks. A single key is used for the encryption. An AES-128 Encryption engine sits on the integrated memory controller thereby offering real-time per page table entry encryption - this works across execution cores, network, storage, graphics, and any other I/O access that goes through the DMA. SME incurs additional latency tax only for encrypted pages.

 

AMD also supports Transparent SME (TSME) on their workstation-class PRO (Performance, Reliability, Opportunity) processors in addition to the server models. TSME is subset of SME limited to base encryption without OS/HV involvement, allowing for legacy OS/HV software support. In this mode, all memory is encrypted regardless of the value of the C-bit on any particular page. When this mode is enabled, SME and SEV are not available.

 

Quote

Secure Encrypted Virtualization (SEV) is a more specialized version of SME whereby individual keys can be used per hypervisor and per VM, a cluster of VMs, or a container. This allows the hypervisor memory to be encrypted and cryptographically isolated from the guest machines. Additionally SEV can work alongside unencrypted VMs from the same hypervisor. All this functionality is integrated and works with existing AMD-V technology.

 

 

I'm not sure if the ARM processor on EPYC is different from Ryzen that is used for PSP, SME & SEV for EPYC. The cache and memory architecture has to be designed to support this too, the security processor itself doesn't facilitate it solely. If I had to guess I would say it is the same and it's just platform segmentation.

 

I think the best place to get some answers you want is the official replies from AMD around speculative execution, they say why they are unlikely to be affected. Whether you believe that or will actually hold true is up to you and pretty much time will tell. None of us can see in to the future.

[mr moose]

10 hours ago, Kisai said:

If you notice, I was pointing to how the FDIV bug was the reason why Intel products were being over-engineered and then something around Haswell (2014) changed and now there are critical bugs being missed in validation, and it appears the entire design of the chip since Skylake has been something of insufficient validation.

 

These bugs didn't come out of thin air.

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf

116 bugs, 0 fixed.

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf

173 bugs, 0 fixed.

 

https://cdrdv2.intel.com/v1/dl/getcontent/332689

188 bugs in Skylake, 0 fixed.

 

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/7th-gen-core-family-spec-update.pdf

 

There are 145 bugs in the 7th Generation and Kaby-Lake-R chips. Only 18 are "fixed".

 

https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/8th-gen-core-spec-update.pdf

 

137 bugs, only 7 fixed.

 

 

You know there is a difference between a bug, a bug that can be fixed, a bug that needs to be fixed and importantly the difference between all that and the reason any bugs exist.   You are implying a motive.