AMD Processors Since 2011 Hit with Cache Attack Vulnerabilities: Take A Way

[TheoneandonlyMrK]

I do know the history. I would suspect better than most. Still, "nothing that is touched by Intel" is quite extreme, don't you think?
In line with the context used here, do you think we should dismiss any and all research papers Intel has been sponsoring?
What events? This was disclosed to AMD last August and published now. Timing a 6-month window would seem too big of a hassle to even try.

Edit:
This is kind of weird though. Instead of discussing what the paper found, whether this has impact or merit (it should, being an academic paper which I assume is peer reviewed), we are discussing Intel because there is a sidenote in the paper that Intel supported researchers. This kind of support is not exactly abnormal.

No security notice should be dismissed only considered correctly.
We can only hope these companies work better to maintain our security and not just to maintain market share.
To be fair researchers need pay too, and if intel were not paying some other nation state would be. probably would not disclose it to the company and would develop a zero day out of it, not good.
Finally hopefully And shore up this hole soon, somehow.

 

[Steevo]

So a competitive company paid for them to find security holes in their competitors product and then released the findings at an ideal time for company I.

What are the chances this is easily mitigated, and also, at this data level it seems it would slow the machine to a crawl to actually implement, and what about memory encryption, the processor doesn't know what the data being processed is.

Either way, I believe we are at a milestone here for both companies, where reverse engineering is going to reveal more issues of varying severity as they snipe at each other. At the end of the day we the consumer win with more secure products.

 

[sutyi]

Graz University of Technology has been in the forefront of security vulnerabilities research since Spectre and Meltdown. At least three of the authors of this paper were also among authors of their Meltdown paper and at least one was among authors of their Spectre paper.

I absolutely do not get the instant dismissal when someone spots Intel somewhere.

Oh AMD... please never change?

I only tried to poke fun at the white paper, was not expecting such serious reactions to be honest.

Funding research on security problems that affects your own CPU designs, as well as your competitors is one thing.
Funding research to reverse engineer your competitors CPU design to uncover potential security problems is another.

In this paper, we present the first attacks on cache way predictors. For this purpose, we reverse-engineered the undocumented hashfunction of AMD’s L1D cache way predictor in microarchitectures from 2001 up to 2019. We discovered two different hash functions that have been implemented in AMD’s way predictors. Knowledge of these functions is the basis of our attack techniques.

...this is my "issue" with this finding.

Kinda like your neighbor with bad gardening skills is hiring some blokes to go over to your front lawn to dig a fresh new a hole into it.
Then said blokes go in front of their freshly dug hole while pointing at it and be like: "Yo everybody this a**hole has a hole in his lawn!"
Then you be like with standing in your doorway with a coffee mug and crumpled news paper: "Well no sh*t, you just dug one..."

So in this new cache issue...
Is this a problem? It is now.
Should AMD do something about it? Also yes, if they can.

Nice race to the bottom, guys. You can crawl back into your hole now and leave this for the adults.

No worries I'll crawl back to by cave as suggested.

 

[londiste]

Funding research on security problems that affects your own CPU designs, as well as your competitors is one thing.
Funding research to reverse engineer your competitors CPU design to uncover potential security problems is another.

As mentioned in couple comments already, other security vulnerability papers specific to Intel CPUs - at least Fallout (one of MDS group) and Cacheout - also mention AMD in the exact same wording - generous gift.

Research into all kinds of undocumented functionalities is a constant effort. For example a link about finding undocumented opcodes was making rounds last week - https://www.cattius.com/images/undocumented-cpu-behavior.pdf. Edit: Now that I look at it, the presentation seems to originate from the same Graz TU.

 

[moob]

Supposedly this only allows for short snippets of data and might not even be usable for a full password.

Even the authors said it's not nearly as severe as other vulnerabilities:

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

 

[Athlonite]

does it require actually having physical access to the computer or can this be done via the internet with some form of malware either way it looks like a lot of work just compromise a system when there are far easier way to do it

 

[mtcn77]

does it require actually having physical access to the computer or can this be done via the internet with some form of malware either way it looks like a lot of work just compromise a system when there are far easier way to do it

They say it can be happenstanced in lockstep with knowing which branch will not be taken, in effect downloading the data you want. But it can only occur in misses, still.

 

[Totally]

To ask some valid questions instead of continuing the bashing of AMD vs. Intel - under what circumstance can this be used?

Same jokes as with Intel's vulns where the attacker already needs to have full admin access to the system?
Can this be used from outside sources without actual access?
Can this be exploited via malicious websites?

Those questions should be discussed here....

That's what I'm wondering myself,can this actually be exploited? is there a proof of concept?

 

[AlB80]

1. TaW is not a vulnerability
2. TaW uses collisions in L1D way predictor. TaW is an another one side-channel, like cache-collisions and branch buffers, that can be used by other flaws, like Spectre V1&2
3. TaW can be used to weak ASLR

 

[DeathtoGnomes]

Patiently awaiting AMDs reply.

Intels contributions to the research may be innocent or there may be other motives, we'll never know exactly. Timing is everything.

 

[user556]

Given Intel had ten months of preparation for the public release of LVI vulnerability - the very next day, I'm gonna be the cynic here and say Intel deliberately orchestrated this maneuver. And the lead researcher's honesty here is suspect at best.

 

[medi01]

Ok, this is some scary stuff. AMD has a serious problem to solve.

In the referenced PDF, section 5.2.3, a method is described by which Javascript itself can be configured to attack a system and supply harvested data straight through both Chrome and Firefox browsers. Theoretically, ANY browser that uses Javascript(99%) can potentially be used to attack a subject system.

It will be interesting to review the analysis and CVE for these new vulnerabilities.

It is a Spectre kind of attack, already addressed by, wait for it.... Spectre fixes.

Patiently awaiting AMDs reply.

AMD rep replied to toms, with what I've said above.

 

[lexluthermiester]

It is a Spectre kind of attack, already addressed by, wait for it.... Spectre fixes.

Perhaps you should re-read the documentation..

 

[medi01]

Perhaps you should re-read the documentation..

Or perhaps you should take what "sponsored by Intel" team says about AMD processors with a grain of salt.

New AMD Side Channel Attacks Discovered, Impacts Zen Architecture (AMD Responds)

AMD processors from 2011 to 2019 impacted

www.tomshardware.com

 

[EarthDog]

Or perhaps you should take what "sponsored by Intel" team says about AMD processors with a grain of salt.

View attachment 147900

New AMD Side Channel Attacks Discovered, Impacts Zen Architecture (AMD Responds)

AMD processors from 2011 to 2019 impacted

www.tomshardware.com

From your own article.....

The researchers do not agree, stating that this vulnerability is still active. Until the two sides agree it isn't possible to ascertain which viewpoint is more accurate. We'll update as necessary and keep an eye out for a CVE.

 

[mtcn77]

From your own article.....

From what I've garnered from techspot's review, the metadata is whether data is in l1d, or not - not it is vulnerable. They do a ping check to see if it is in access, or not. Obviously, not, if it accesses quickly(it is already overwritten a couple of times and now 'cold').

 

[londiste]

The concern about Take A Way is this:

Aside from the ASLR breaks, the two attacks are just building blocks similar to Prime+Probe and Flush+Reload.

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

 

[mtcn77]

...

That is a supposition. I get it, you wanna equate it with LVI. However, there needs to be a primer for that to function.

 

[londiste]

I have not said anything about LVI, neither does the link I posted. Why would it be related? LVI and Take A Way are not related in any tangible way, are they?
Author of that tweet is one of the authors of Take A Way paper, he is likely to know what he claims.

 

[mtcn77]

I have not said anything about LVI, neither does the link I posted. Why would it be related? LVI and Take A Way are not related in any tangible way, are they?
Author of that tweet is one of the authors of Take A Way paper, he is likely to know what he claims.

I just looked at flush and reload. It is the same with the first claimed vector. How is that an attack? Don't share memory, how hard is it to fence private memory. I mean, how could they be so stupid to build a firewall and let you go around the fence...
Please, hold on for my rand on the second clause, it is coming with more effervescence i must add.

I might be railing too hard. Lost my train of thought for a moment.
Let's look at it the other way - how easy would it be to cover latency imprint by masking with false accesses? It boggles my mind how much validation is accredited to indirect proofs.

 

[londiste]

Let's look at it the other way - how easy would it be to cover latency imprint by masking with false accesses?

Wouldn't that defeat the purpose of a cache or at least reduce its effectiveness?

 

[mtcn77]

Wouldn't that defeat the purpose of a cache or at least reduce its effectiveness?

Lol, comparative to SGX mitigation?
I'm not such a cave troll, but we survived rowhammer, haven't we?