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

[Kisai]

7 hours ago, mr moose said:

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. 

Look, All I'm saying is that Intel has been releasing chips with known bugs in them, and while the bug counts are going down, they're kind of insane if you look at the first gen P2/P3 chips.

http://datasheets.chipdb.org/Intel/x86/Pentium II/SpecUpdate/24333703.pdf

 

29 bugs in the PII, 12 fixed. Yes almost half. Bug #18 was one I ran into if I tried to play Diablo II. Or play h.263/divx movies.

 

http://datasheets.chipdb.org/Intel/x86/Pentium III/SpecUpdate/24445358.pdf

8 years BTW of updates.

109 bugs in the PIII spanning the entire life cycle. 29 fixed.

 

I'm sure some of these bugs are worked around in compilers and operating system kernels. But at what point are the bugs bad enough to not ship a product? All these side-channel bugs, despite being difficult for the end-user to trip, are easily tripped in virtualization, and security features are what is being virtualized on desktop PC's. In servers, even less bugs are tolerable, and side-channel attacks basically torpedo that CPU from being usable in a "shared" hosting system like Amazon Web Services, or any VPS system. Like I've been a strong advocate for staying away from virtualized nonsense for precisely this kind of thing. You can not trust someone else on the same machine, ever. Nobody should have shell access to a server nor the ability to execute programs without the administrator of the machine knowing about it, and I'm sure the sidechannel attacks can all be triggered in programming languages like php and node.js, since they can clearly be triggered in javascript on desktops.

 

Some sidechannel attacks of course are going to be completely impractical, because you need to know where in memory the thing you are looking for is. But if you know who your target is, and you can run a binary on the machine in any language, you can probably execute a sidechannel attack.

 

I don't believe AMD or Intel sets out to make the fastest chip possible sacrificing speed for it, I believe Intel simply didn't care and wanted to stay ahead, so they skimped on validation.

[Arika]

11 minutes ago, Kisai said:

I believe Intel simply didn't care and wanted to stay ahead, so they skimped on validation.

given how highly specific some of these vulnerabilities are and how long it took for them to come to light after this many years, it's not something that they would have tested for because it's not a vulnerability they would even have thought of.

[Kisai]

16 minutes ago, Arika S said:

given how highly specific some of these vulnerabilities are and how long it took for them to come to light after this many years, it's not something that they would have tested for because it's not a vulnerability they would even have thought of.

Coffee-Lake Refresh and Ice Lake would like a word with ya.

https://www.intel.com/content/www/us/en/products/docs/processors/core/10th-gen-core-families-specification-update.html

 

44 bugs, 5 fixed. 

 

I believe for Intel to truely fix the sidechannel problems they would have to throw out the current Core design that we've had since 2009

 

[mr moose]

4 hours ago, Kisai said:

Look, All I'm saying is that Intel has been releasing chips with known bugs in them, and while the bug counts are going down, they're kind of insane if you look at the first gen P2/P3 chips.

http://datasheets.chipdb.org/Intel/x86/Pentium II/SpecUpdate/24333703.pdf

 

29 bugs in the PII, 12 fixed. Yes almost half. Bug #18 was one I ran into if I tried to play Diablo II. Or play h.263/divx movies.

 

http://datasheets.chipdb.org/Intel/x86/Pentium III/SpecUpdate/24445358.pdf

8 years BTW of updates.

109 bugs in the PIII spanning the entire life cycle. 29 fixed.

 

I'm sure some of these bugs are worked around in compilers and operating system kernels. But at what point are the bugs bad enough to not ship a product? All these side-channel bugs, despite being difficult for the end-user to trip, are easily tripped in virtualization, and security features are what is being virtualized on desktop PC's. In servers, even less bugs are tolerable, and side-channel attacks basically torpedo that CPU from being usable in a "shared" hosting system like Amazon Web Services, or any VPS system. Like I've been a strong advocate for staying away from virtualized nonsense for precisely this kind of thing. You can not trust someone else on the same machine, ever. Nobody should have shell access to a server nor the ability to execute programs without the administrator of the machine knowing about it, and I'm sure the sidechannel attacks can all be triggered in programming languages like php and node.js, since they can clearly be triggered in javascript on desktops.

 

Some sidechannel attacks of course are going to be completely impractical, because you need to know where in memory the thing you are looking for is. But if you know who your target is, and you can run a binary on the machine in any language, you can probably execute a sidechannel attack.

 

I don't believe AMD or Intel sets out to make the fastest chip possible sacrificing speed for it, I believe Intel simply didn't care and wanted to stay ahead, so they skimped on validation.

I think you would be surprised to see all CPU and device of this complexity have that many bugs.

 

Here is the errata and bugs for the current Ryzens:

https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

Page 12 has 28 issues with no fixes planned.

 

But this means nothing in reality.  Just like 109 bugs in the Pentium 3 means nothing in reality.  They made them work, they closed exploits when they occurred and on top of all that you are still trying to insinuate that this is the end result of intentionally not caring about security.    Motive cannot be that easily established beyond occams razor in such a complex array of activities.

[TechyBen]

17 hours ago, Mira Yurizaki said:

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.

But what do? Do you not buy the safe option because there may be 1000s of unknowns? And buy the dangerous known option? That's like eating poison berries because "the strawberries might be from mars about to attack us".... Well, not as extreme. But still...

 

I agree, no one is perfect. But Intel *dropped the ball* here. At least AMD have only dropped it performance wise.

 

[thechinchinsong]

4 hours ago, mr moose said:

I think you would be surprised to see all CPU and device of this complexity have that many bugs.

 

Here is the errata and bugs for the current Ryzens:

https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

Page 12 has 28 issues with no fixes planned.

 

But this means nothing in reality.  Just like 109 bugs in the Pentium 3 means nothing in reality.  They made them work, they closed exploits when they occurred and on top of all that you are still trying to insinuate that this is the end result of intentionally not caring about security.    Motive cannot be that easily established beyond occams razor in such a complex array of activities.

I feel as if most of these issues don't actually mean much for security. They just simply are more important for Intel because they are under more scrutiny. When AMD gets the same scrutiny, people will care about the Ryzen errata more.

[Kisai]

5 hours ago, mr moose said:

I think you would be surprised to see all CPU and device of this complexity have that many bugs.

 

Here is the errata and bugs for the current Ryzens:

https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

Page 12 has 28 issues with no fixes planned.

 

But this means nothing in reality.  Just like 109 bugs in the Pentium 3 means nothing in reality.  They made them work, they closed exploits when they occurred and on top of all that you are still trying to insinuate that this is the end result of intentionally not caring about security.    Motive cannot be that easily established beyond occams razor in such a complex array of activities.

Take note of which of those issues are fixed in the 1st gen((ZP-B1) (Ryzen and Threadripper) and 2nd gen (PiR-B2) (Second generation Ryzen) EPYC (ZP-B2).

 

46 issues, 28, "No fix planned", 18 of those issues affect 1st gen Ryzen, 2 affect second generation Ryzen, 9 affect EYPC. If I saw this table before buying, I'd obviously pick the second generation Ryzen chips over the first.

 

Another thing to consider if you actually want to examine a lot of these bugs is why some bugs were not fixed.

 

For example

IOMMU:

Quote

913 IOMMU Incorrectly Issues Guest Page Table Walk Request as Non-coherent Request

 

Description

When software issues a guest table walk request with DTE.SD=1, IOMMU will issue the table walk request as a non-coherent request just based on the DTE.SD value. It ignores the intermediate guest page PTE.FC value to properly determine if the guest page table walk request should be a coherent request.

 

Potential Effect on System

A guest page table walk request is issued as non-coherent instead of coherent even when host PTE.FC (Force Coherent) is set.

 

Suggested Workaround

 

Software should program DTE.SD=0.

 

Fix Planned No fix planned

So reading this, it sounds like it might have a minor performance impact, and can be worked around at the compiler level.

 

Meanwhile something that's fixed:

Quote

1017 FERR (Legacy Floating Point Error) for Thread 0 May be Incorrectly Cleared When Thread 1 Clears Its FERR

 

Description

 

Under a highly specific and detailed set of internal timing conditions, if thread 0 enters HALT or MWAIT with a pending FERR, then if thread 1 clears its FERR, the FERR for thread 0 may also incorrectly be cleared.

 

Potential Effect on System

Unpredictable system behavior.

 

Suggested Workaround

None

 

Fix Planned Yes

I'm assuming that's a microcode fix, but note this bug does not affect 2nd generation Ryzen.

 

The description itself is very on the "improbable to replicate in the real world" level.

 

This one is bigger though:

Quote

1033 A Lock Operation May Cause the System to Hang

 

Description

Under a highly specific and detailed set of internal timing conditions, a Lock operation may cause the system to hang.

 

Potential Effect on System

The system may hang or reset.

 

Suggested Workaround

Program MSRC001_1020[4] to 1b. System software may contain the workaround for this erratum.

 

Fix Planned

Yes

Again, it's something that can be worked around, and thus it can be fixed with the compiler. Does not affect second generation Ryzen or EPYC.

 

I don't have time right now to go look for similar bugs in the Intel errata, because quite frankly it's an apples and bannanas comparison to compare what is effectively a bunch of iterations of the same Intel "core" design from 2009 to the Ryzen from 2017

 

Intel at this point really should retire "Core" i(series) and come up with a brand that says "yes we did in fact put security at the forefront"

 

[Mira Yurizaki]

4 hours ago, TechyBen said:

But what do? Do you not buy the safe option because there may be 1000s of unknowns? And buy the dangerous known option? That's like eating poison berries because "the strawberries might be from mars about to attack us".... Well, not as extreme. But still...

Knowing that there are issues in the system either means:

• They've been fixed already
• There's a mitigation in place to prevent or reduce the effects of it should someone attempt to exploit it

Most items in the CVE list are known by the producer of whatever it is that the CVE item is against and given ample time to figure something out by the time it's made public.

 

Besides, by going with the logic that "having more knowns is dangerous", we should stop using Linux because it has nearly five times the CVE entries as Windows 10. And Windows 98 has 100 times fewer CVE entries, meaning it's obviously a more secure OS

 

This mindset applies to real life issues as well. I'm more paranoid walking into a nicer looking establishment that I don't know anything about than a shadier looking one I've been to 100 times.

1 hour ago, thechinchinsong said:

I feel as if most of these issues don't actually mean much for security.

Innocuous looking issues can lead to side effects that can allow someone to break a system in ways you didn't expect.

[thechinchinsong]

1 hour ago, Mira Yurizaki said:

Innocuous looking issues can lead to side effects that can allow someone to break a system in ways you didn't expect.

That's true and goes for AMD as well as Intel. It's just that AMD hasn't had the same scrutiny or use.

[Canoe]

And my older hexcore i7 970 CPU is not on the list. I get to dodge this bullet due to running older tech! Bonus for getting a high performer that still handles most modern tasks, well or well enough.

 

This article provides a good overview. Includes links to various researchers' work.

https://www.theregister.co.uk/2020/01/28/intel_processor_data_leak/

 

Quote

Intel on Monday issued a processor data leakage advisory, describing two chip architecture flaws, one of which it tried to fix twice before.

 

The memo, INTEL-SA-00329, covers two security vulnerabilities: CVE-2020-0548, dubbed Vector Register Sampling, and rated 2.8 low severity, and CVE-2020-0549, described as L1D Eviction Sampling (L1Des) Leakage, and rated 6.5 medium severity.

The flaws allow the potential disclosure of privileged information, which is of particular concern in multi-tenant cloud environments. For example, server hosting biz DigitalOcean warned that the issue "means a malicious actor could theoretically use a Droplet to infer partial data used by another Droplet on the same physical host."

In short, the design flaws can be exploited by rogue users or malware on a system to snoop on private data, such as passwords and keys, that should be off limits. As with Meltdown and Spectre, we've yet to see any meaningful malicious exploitation of these holes in the wild, though that doesn't mean they can be ignored.

 

[pas008]

3 hours ago, Kisai said:

 

Intel at this point really should retire "Core" i(series) and come up with a brand that says "yes we did in fact put security at the forefront"

 

this "bugs" me

considering intel has bug bounty program that pays well

that everyone is attacking their products for that bug money

if they are paying for entities to continue to attack their products

does that not scream we care and want to be secure?

 

but I do agree they need to retire that arch soon

 

[mr moose]

9 hours ago, Kisai said:

Take note of which of those issues are fixed in the 1st gen((ZP-B1) (Ryzen and Threadripper) and 2nd gen (PiR-B2) (Second generation Ryzen) EPYC (ZP-B2).

 

46 issues, 28, "No fix planned", 18 of those issues affect 1st gen Ryzen, 2 affect second generation Ryzen, 9 affect EYPC. If I saw this table before buying, I'd obviously pick the second generation Ryzen chips over the first.

 

Another thing to consider if you actually want to examine a lot of these bugs is why some bugs were not fixed.

 

For example

IOMMU:

So reading this, it sounds like it might have a minor performance impact, and can be worked around at the compiler level.

 

Meanwhile something that's fixed:

I'm assuming that's a microcode fix, but note this bug does not affect 2nd generation Ryzen.

 

The description itself is very on the "improbable to replicate in the real world" level.

 

This one is bigger though:

Again, it's something that can be worked around, and thus it can be fixed with the compiler. Does not affect second generation Ryzen or EPYC.

 

I don't have time right now to go look for similar bugs in the Intel errata, because quite frankly it's an apples and bannanas comparison to compare what is effectively a bunch of iterations of the same Intel "core" design from 2009 to the Ryzen from 2017

 

Intel at this point really should retire "Core" i(series) and come up with a brand that says "yes we did in fact put security at the forefront"

 

 

So it's ok for AMD to not fix bugs because you personally don't consider some of them to be important but when Intel don't fix bugs of a similar nature it is because they don't care about security?

 

One last attempt at putting things in perspective:

 

Ryzen has been out for 3 years, the bugs you are pointing to were discovered in 1994. Give ryzen the same product life span and there will be exactly the same number of bugs and flaws (law of averages almost guarantees it). Discovering bugs in processors is not a new thing and does not mean anything with regard to the resolve of a company to address security.  Intel cannot just stop producing what is essentially the core of their business because it has a security flaw which can be mitigated with software updates for now.    Is it a shame? yes, is it an indication of motive? NO.

 

 

 

 

[Kisai]

4 hours ago, mr moose said:

 

So it's ok for AMD to not fix bugs because you personally don't consider some of them to be important but when Intel don't fix bugs of a similar nature it is because they don't care about security?

 

One last attempt at putting things in perspective:

 

Ryzen has been out for 3 years, the bugs you are pointing to were discovered in 1994. Give ryzen the same product life span and there will be exactly the same number of bugs and flaws (law of averages almost guarantees it). Discovering bugs in processors is not a new thing and does not mean anything with regard to the resolve of a company to address security.  Intel cannot just stop producing what is essentially the core of their business because it has a security flaw which can be mitigated with software updates for now.    Is it a shame? yes, is it an indication of motive? NO.

 

 

 

 

Nowhere did I say Intel's motive was to sell bad products, that's your imagination. Intel has not been putting security in focus, and I'm more willing to believe some the blogs following the security issues than random people on the internet who don't work for Intel or AMD. If Intel wants to clean up their image, they will retire the core brand and release something that was engineered with security first, and you'll watch as they have to play catch up again like they did with x86-64 to AMD.

[mr moose]

46 minutes ago, Kisai said:

Nowhere did I say Intel's motive was to sell bad products, that's your imagination.

I didn't make that claim about your posts. I have been very clear about what i was responding to.:

 

 

5 hours ago, mr moose said:

 

So it's ok for AMD to not fix bugs because you personally don't consider some of them to be important but when Intel don't fix bugs of a similar nature it is because they don't care about security?

...

 Intel cannot just stop producing what is essentially the core of their business because it has a security flaw which can be mitigated with software updates for now.    Is it a shame? yes, is it an indication of motive? NO.

 

 

 

 

 

16 hours ago, mr moose said:

I think you would be surprised to see all CPU and device of this complexity have that many bugs.

 

Here is the errata and bugs for the current Ryzens:

https://www.amd.com/system/files/TechDocs/55449_Fam_17h_M_00h-0Fh_Rev_Guide.pdf

Page 12 has 28 issues with no fixes planned.

 

But this means nothing in reality.  Just like 109 bugs in the Pentium 3 means nothing in reality.  They made them work, they closed exploits when they occurred and on top of all that you are still trying to insinuate that this is the end result of intentionally not caring about security.    Motive cannot be that easily established beyond occams razor in such a complex array of activities.

 

On 1/29/2020 at 8:54 AM, mr moose said:

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. 

 

 

In every post I have said you can't imply a motive about security,  I said nothing about general quality,

46 minutes ago, Kisai said:

Intel has not been putting security in focus, and I'm more willing to believe some the blogs following the security issues than random people on the internet who don't work for Intel or AMD. If Intel wants to clean up their image, they will retire the core brand and release something that was engineered with security first, and you'll watch as they have to play catch up again like they did with x86-64 to AMD.

Believe whatever you want, occams razor is still a thing.

[TechyBen]

19 hours ago, Mira Yurizaki said:

Knowing that there are issues in the system either means:

• They've been fixed already
• There's a mitigation in place to prevent or reduce the effects of it should someone attempt to exploit it

Most items in the CVE list are known by the producer of whatever it is that the CVE item is against and given ample time to figure something out by the time it's made public.

 

Besides, by going with the logic that "having more knowns is dangerous", we should stop using Linux because it has nearly five times the CVE entries as Windows 10. And Windows 98 has 100 times fewer CVE entries, meaning it's obviously a more secure OS

 

This mindset applies to real life issues as well. I'm more paranoid walking into a nicer looking establishment that I don't know anything about than a shadier looking one I've been to 100 times.

Innocuous looking issues can lead to side effects that can allow someone to break a system in ways you didn't expect.

"They've been fixed already". Hahahahahaha. Nope. So... yeah. That's bad advice. Like saying "they fixed it already" for a lot of these "cannot fix" exploits?

[pas008]

13 hours ago, Kisai said:

Nowhere did I say Intel's motive was to sell bad products, that's your imagination. Intel has not been putting security in focus, and I'm more willing to believe some the blogs following the security issues than random people on the internet who don't work for Intel or AMD. If Intel wants to clean up their image, they will retire the core brand and release something that was engineered with security first, and you'll watch as they have to play catch up again like they did with x86-64 to AMD.

 

they been doing bug bounty for how long

so its not in focus now

 

read below

quoted you before but you seem to think them paying outsiders to attack their products isnt them being focused

19 hours ago, pas008 said:

this "bugs" me

considering intel has bug bounty program that pays well

that everyone is attacking their products for that bug money

if they are paying for entities to continue to attack their products

does that not scream we care and want to be secure?

 

but I do agree they need to retire that arch soon

 

 

[Norwegiantweaker]

On 1/27/2020 at 11:08 PM, 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.

bet chu intel got paid by the government to put in backdoors that are now being discovered

[Tristerin]

Im less surprised that using the same rebaked architecture keeps having its vulnerabilities continue to be exploited.  If something is around LONG enough (++++++++++++++) you can eventually attach it from all of the angles.