Security Implications of AMD’s Cache Way Predictors - funding by Intel

[Master_shake_]

Except, they’re really not. YOU are making it an issue. No one would have taken a second look at this if Intel wasn’t mentioned. Also, funny how you ignore my statment about AMD not considering the kernel stuff as a deal breaker.

AMD straight up said the problem was fixed 2 years ago.

 

[GoodBoy]

Well this would take more then a simple kernel exploit... its a custom kernel that is ignoring memory read permissions that isn't a minor change of a few bits. You can't make these types of changes to a running kernel. You would have to replace it. There isn't a java script that is going to run over a browser or something that is going to tell your kernel to stop doing basic memory permission checks so it can over right the bits required. Nor one that is going to replace your kernel.

Right. For the typical home user, this is not a big deal. That doesn't mean it isn't a valid finding that it is a good thing has been fixed.

This most affects customers of cloud data services that run on the affected processors. Bad guy wants to get into another vm running in the same environment, all he has to do is buy his own vm on the service, install the modified linux kernel in his OS, and then he could use the exploit to see other customers' data. Corporate espionage, spy on a competitor, bad state actor, spy on foreign companies/governments. The main target for this would be US Govt and US companies running on Amazon or another big cloud that is on these chips. It's the same reason it was really concerning when the Intel vulnerabilities were announced.

Any downplaying of this issue because it requires a "modified linux kernel" is ignoring that there is real impact and security concerns, and completely real scenarios that would keep a CEO up at night.

What makes this one completely over the top silly .... is this is a already mitigated "exploit".

Any credible security researcher waits until the affected vendor fixes the issue before it is publicly reported.

 

[ChadD]

Any credible security researcher waits until the affected vendor fixes the issue before it is publicly reported.

Well AMD believes this isn't even a new attack....

https://www.amd.com/en/corporate/product-security

"We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks. "

AMD fixed the cache issue they are talking about a couple years ago (via OS software patches) ... not months ago. Someone tried to make this non story a story. After going through the paper I wonder what the point was.... running old versions of kernels without mitigation so you can attack something isn't proof of anything new. We always knew AMD IBM and ARM had some exposure to side channel attacks as well... the holes where just not as gaping wide as Intels where. Most of the side channel stuff is fixed in software kernel patches for all CPUs, Intel has had to patch some actual hardware that was executing requests prior to getting the OK from the kernel permission system. (hence the faster operation as it was skipping one extra communication point with software) You can do timing based attacks against any CPU with speculation... which is why the kernel has to be hyper vigilant about permissions. Which all currently patched OSs are. This researcher had to disable all of that to basically do the thing the original side channel stuff did, back when the kernel had a few loop holes that allowed them to access kernel level memory space. That isn't really possible right now... unless someone finds a new hole which this isn't.

 

[Derangel]

AMD straight up said the problem was fixed 2 years ago.

They said it was “mitigated”, not fixed, and that it wasn’t a brand new side channel attack. Co-author Daniel Gruss said that the side channel still exists and can still be exploited.

And, once again, AMD made no mention of the kernel modification that people are up in arms about, which they would have if doing so was such a serious thing.

 

[ChadD]

They said it was “mitigated”, not fixed, and that it wasn’t a brand new side channel attack. Co-author Daniel Gruss said that the side channel still exists and can still be exploited.

And, once again, AMD made no mention of the kernel modification that people are up in arms about, which they would have if doing so was such a serious thing.

https://www.intel.ca/content/www/ca...ngineering-new-protections-into-hardware.html

Go through Intels CPUs and their list of side channel fixes. Notice how a lot of them are "software".

There is no way to fix anything for a timing attack. It isn't broken its working as intended. It would be like saying a car engine is broken cause if you put your ear to the hood you can hear the cylinders moving.

This is the same way encrypted wi fi is broken into. Its not that anything is broken. If you listen long enough you can rebuild the underlying pattern. This is true of all CPUs. The fix has to come in the form of software that makes it harder and hopefully impossible to listen for the pattern to begin with, or at least make sure you can't listen to kernel level code execution if you don't have kernel level permissions.

Something like V1... effected everyone. The fix is in software at the kernel level, for everyone Intel AMD IBM ARM. Something like V3... didn't effect AMD, cause it relied on a cache system that was allowing reads of data before it was overwritten. (Intel choose to overwrite cache space instead of blanking it)... allowing user land software to briefly see bits of kernel level code that was left behind before being overwritten.) So looking at their chart you see software and hardware mitigation for V3.... as it was a hardware flaw. You can correct it in software, but hardware is obviously the better fastest option.

This is a alternate V1 as I understand it that does apply to AMD as their cache is unique. But that doesn't change the simple fact that these L1 cache timing attacks where headed off 2 years ago already in software. Which is the only fix that would ever come to be.... as again this is normal operation, the only abnormal thing here is being able to listen to the cache and reconstruct a picture of what is passing through it. That isn't possible anymore unless you run a old unpatched OS or have had your kernel replaced. At that point a hacker would be better off just using V1... which would effect everyones CPU, and I don't know for sure but would assume work a lot faster and more reliably on AMD then this novel version.

 

[blandead]

Hmm so JavaScript via web browsers (probably only certain versions). Leaked information seems to be limited. Still seems more secure than Intel's unpatched spectre variant 1 (even upcoming ice lake)

The researchers also noted that unlike the Spectre and Meltdown vulnerabilities, the Take A Way exploits only leak a "few bits of metadata," as opposed to providing full access to data​

 

[JosiahBradley]

Everyone in this thread, chill lol. The paper is purely academic and clearly isn't meant to incite panic. Researchers research things. While the tone of the paper is slightly biased it makes note several times that AMD is actually the more secure product in the fact they could not use a number of exploits to join with this side channel exploit. There is no major conspiracy here on Intel trying to fund research to shed bad light on anyone. There are not PhD students looking to break big into the global espionage field lol. The only problem here are people reading the title of the paper and posting tiny bits on social media trying to blow it out of proportion. Imagine if no one research atomic weapons, would we even have awesome nuclear power generators today? So take a step back and just enjoy the fact people are learning and news outlets will always blow things outta proportion cause they aren't in the field.

/thread please.