AMD, boffins clash over chip data-leak claims: New side-channel holes in decades of cores, CPU maker disagrees AMD processors sold between 2011 and 2019 are vulnerable to two side-channel attacks that can extract kernel data and secrets, according to a new research paper. In a paper [PDF] titled, "Take A Way: Exploring the Security Implications of AMD’s Cache Way Predictors," six boffins – Moritz Lipp, Vedad Hadžić, Michael Schwarz, …
"So not all FX and Ryzen architecture chips to date are affected?"
They very likely are affected if these findings are true.
It would we very difficult for the boffins to obtain every single AMD CPU (since FX) for testing since AMD has made custom chips for their clients - like the Epyc 7571 they had tested. As long as each microarchitecture is tested with a couple of representative samples (which they've done) it is in my eyes very likely that all of them are affected.
Was pre-existing side channel exploit code that has been mitigated? Seems that if you have patched for the existing side channel attacks then this method as outlined in the paper would not work. Of course this doesn't mean a new side channel attack that has not been discovered and mitigated could not take advantage of this exploit but that is a harder attack vector than many others are already out there.
I'm still a little more concerned with the IME exploit and the many meltdown/spectre variants that my intel chips are vulnerable to - thankfully I am probably not a high value target.
On reason for client side processing is that PWAs need to have persistence locally to save state. IF the js code is trusted, this is a more secure process.
Personally, I'm afraid I'm biased. I do not download non-trusted code and run it - if that can be prevented; and if not, only run in a sandbox (ie a browser.)
In case you were wondering about all the downvotes, this article is about AMD making their own mistakes, entirely separate from Intel.
The fact that this is somewhat similar to Melthdown says more about where researchers are currently looking for potential vulnerabilities, than it does about AMD or Intel's design decisions.
I agree and upvoted for the first statement.
However, I do not believe the second statement is accurate. As far as I can tell in my admittedly non-expert - vague would be more appropriate - understanding, this is not a Meltdown-equivalent or similar attack.
These attacks seem to be more Spectre-equivalent attacks.
Which is not to say that they aren't, potentially, serious.
I assume this has or will soon be weaponized by all major security services (and hacking tool creators like NSO) but, even so, I can't see it as a common attack vector.
For the normal person, like the Intel vulnerability kerfuffle, it doesn't seem to matter. I've got a slew of security issues that I am much more concerned about.
That said, both here and in the Intel case, it would seem that trying to make your chips seem to run faster by tweaks to the software can and sometimes does introduce low level security issues that may not be correctable. OTOH the benefits to the user experience probably means that this will not be the last of these articles.
In a multi-user or multi-tasked 8085 environment you had every security problem imaginable because it had no memory protection whatsoever.
Due to a variety of factors including - in my opinion at least - poor foresight, this wasn't fixable with a quick microcode update included in your regular patch Tuesday bundle, and so Intel were eventually forced to release an entire new chip design (the 286). Very embarrassing situation.
All the early Z80, 8080 multitasking problems were all in the people writing code who had grown up on single task systems and never considered multitasking before. I used to demo multi-masking to 8080 and Z80 coders and they were always amazed that it was even possible, let alone what the implications were. LOL
Any optimisation, either caching or prediction based on past behaviour (which is just a form of caching), is a potentially exploitable side-channel as it introduces an observable variable timing effect based on potentially privileged data. This is true for hardware or software. The only way to not leak information is for all operations to complete in a deterministic time that does not vary based on the data. This does leave a lot of clever speed up tricks on the table.
@"The only way to not leak information is for all operations to complete in a deterministic time that does not vary based on the data" or you can add "random" delay to all operations.
There are other methods but ultimately whilst all processes share the same space then your are going to see side channel attacks however this is not compulsory, rather it was just easier/cheaper to implement it is possible to make a computer where only the messaging space is common and processes are physically limited to their assigned area.
Shame that when multitasking became common no one thought it was necessary to also change the hardware design, beyond the CPU, so as to keep everything actually separate. Cost and IP was OFC to blame but now we know the current system is beyond repair perhaps it is time to look again, that or just accept that all computers, in their current form, are inherently insecure and untrustworthy. Yes you may mitigate but ultimately the costs of keeping with the current design are only going to increase
When multitasking became common (eg on the Amiga), there was zero separation, because security was much less of a problem. Partly this was because most computers were standalone, and were never connected to a network, so all exploits required physical access.
The big change wasn't multitasking, it was end users being much more likely to run untrusted code on their machines, eg, in the form of javascript from a website.
it was end users being much more likely to run untrusted code on their machines, eg, in the form of javascript from a website
Yes, aside from Javascript, all code running on end-user machines is entirely trustworthy. No vendor has ever released malicious code, deliberately or courtesy of a supply-chain attack.
"researchers"
Intel paycheck collectors?
Do vulnerabilities matter? Intel 245 but AMD less than 20, Intel won and have been pumping $Bs Q after Q!
Not just the vulnerabilities but a lot more important is the design integrity without the cheap shortcut; Intel used partial addresses but AMD didn't!
About using partial addresses, a cheap design shortcut:
People who live on a street with 4-digit addresses can get in each other's houses as long as having addresses with the same last three digits, paying more for "Partial Addresses Inside", amazing!
There's a 200lb security vulnerability setting up the systems in most organisations, so this kind of extreme technical vulnerability is unlikely to be necessary most of the time. In the cases such as national security where this is an issue, I'm certain there are 5 more yet to be documented exploits out there which the national security people are actively using themselves.
Personally I'm more concerned by the general lack of security knowledge in the industry, and the fact that most security "experts" were trained by firewall vendors and nobody else. The outcome is usually poor security, slow IT, and rich firewall vendors.
After the quite well known anti trust case I think people just assume that most attempted hit jobs on AMD come from their competition.
It often seems to be forgotten in the rush to hate on Intel, but AMD processors were vulnerable to Spectre as well, as were ARM and IBM. This has never just been an Intel problem. Intel certainly seem to have been the worst at leaving these kinds of holes, but given that everyone has already been shown to have the same problem to at least some extent, it's not at all surprising that further vulnerabilities have been found.
ARM, at the time, had no spectre vulnerable CPUs being produced, so you are wrong or a shill
As to "the rush to hate Intel", where a company sells a premium product for a lot of money which is fundamentally flawed and still refuses refuses to do a recall then there are reasonable grounds for purchasers to feel that they have been abused. When the same company tries, as you have to muddy the waters rather than 'fess and pay up then dislike can only increase, when the software mitigations the same company offers reduce the performance of their CPU to a level equivalent to a different CPU for at a tiny fraction of the original's selling price then yes I can see hate raising it's ugly head and not, it must be said, without justification
ARM, at the time, had no spectre vulnerable CPUs being produced, so you are wrong or a shill
Irrelevant. ARM had published designs with Spectre-class side-channel vulnerabilities. The Cortex-A75 was also vulnerable to a Meltdown variant (as was POWER). The OP is correct.
...the attacker is assumed to be able to run unprivileged native code on the target machine that's also on the same logical CPU core as the victim.
Presumably while holding a Dodo under one arm and drinking a glass of Unicorn's milk?
Interesting, but for an actual exploit you'd be far better off kidnapping a sysadmin and flaying his fingers until he logs you in remotely.
My view when first reading about Spectre and fellow exploit classes is that they are deadly serious if you are running a virtualised enviroment and have other tenants that you don't trust running on the same physical hardware as you. eg, cloud services hosting VM's. It's obviously a really, really serious issue for people like Amazon who have a bazillion instances spun up each owned by different people who can potentially use software issues to compromise other VM's.
When it comes to your own internal network though it's much less of a concern since by the time somebody has breached security enough to run untrusted code that's not signed (which would be blocked by normal security measures) then the possibility of an exploit that might expose things is less worrying than the fact they could be running a keylogger (if a desktop) or uploading the contents of the server.
How is it flawed? (genuine question btw, i'm quite aware I could have missed something)
In line with Cyber Essentials requirements practically we (and one imagines most other compliant uk companies) have a default security level of "everything is blacklisted" and bits of code that run have to be individually whitelisted by hash to run.
I'm finding it difficult to imagine the train of events that leads to a compromise in this situation. About the only realistic vector is hacking microsoft and injecting your code into one of their updates. I'd note again though that this comes under the heading of "at this point i'd be more worried about what else they could be doing".
...native code on the target machine that's also on the same logical CPU core as the victim
how do you even make that happen ? I mean, if you're on a normal system with thousands of processes that jump from one CPU (core) to another, how do you assure that another unrelated process from another unrelated user will be scheduled on the process you're trying to break ? I've been toying with CPU isolation things, and getting 2 processes to run on the same CPU is difficult, even if you're completely in charge of the entire system.
To me, this "attack" isn't any actual attack as it supposes a scenario that is literally impossible without cooperation from the "victim".
This smells like a smear-job by Intel to minimize their own (repeated) failures.
The only threat that comes to mind for this entire class of threats only actually applies to vendors like Amazon where you could potentially hire a VM on a stolen credit card and then do an exploit on your VM which allows you to compromise data from another customer's VM.
This is however probably not still a particularly useful form of attack compared to the well known Intel issues, and of course if your a normal system with servers on site on your own hardware then of course your utterly unaffected anyway since your not going to hire out a VM to a hacker.
AMD processors sold between 2011 and 2019 are vulnerable to two side-channel attacks that can extract kernel data and secrets, according to a new research paper.
Is it realised that such attacks are also designed to insert kernel data and secrets too.
In Order to Make Future Advanced IntelAIgent Moves which All can Follow from Source to Destination in Preparation for the Enjoyment of All Newly Arrived there.
Here too, for truth to be told. :-)
From the description given, I very much doubt that there is any way in practice for anyone to usefully exploit this vector "in the wild". Like many other recently published vulnerabilities, it is very much theoretical and could only work in a carefully stage-managed artificial situation where far more variables are known than would be the case in any real-life situation. Unless I see something to the contrary, I will continue to believe that the idea that a bit of java code could use this to extract an encryption key is very far-fetched.
"
Demonstrated, not just proposed.
"
If it's the same demo I saw, it comprised of a command line program producing an unexplained output that was claimed to be the contents of memory locations that the code should not have had access to. As a proof of concept that the bug existed it was fine. It was not however claimed that anyone knew what data the memory locations in question were used to store, or that it could be made to target any specific content, so its usefulness to a criminal hacker is rather dubious. Snooping on random locations in several GB of RAM to try to spot something of use to the miscreant would be more time-consuming than a brute-force attack on securely encrypted data.
I would need to see a demo of something useful - such as something that was extracting an encryption key or other sensitive data from a system that it was not uniquely tailored for.
it is very much theoretical and could only work in a carefully stage-managed artificial situation where far more variables are known than would be the case in any real-life situation. ..... Cynic_999
So, and I would not disagree, Cynic_999, it is certainly practical and easily works in VM and AI environments ....... which are important leading sectors and vectors in an ever increasing number of real-life situations.
And I would also most wilfully agree with Michael Wojcik if they were to say .... The ignorance around this class of attack is really quite impressive.
And that ignorance provides a very effective stealth which covers and protects unrivalled progress in novel genres.
And yes, of course it is weaponised to be particularly deadly against certain targets destined for meltdown and destruction/fundamental disruption.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
