AMD Processors From 2011 To 2019 Vulnerable To Two New Attacks (zdnet.com) 71
An anonymous reader quotes a report from ZDNet: AMD processors manufactured between 2011 and 2019 (the time of testing) are vulnerable to two new attacks, research published this week has revealed (PDF). The two new attacks impact the security of the data processed inside the CPU and allow the theft of sensitive information or the downgrade of security features. The research team said it notified AMD of the two issues in August 2019, however, the company has not released microcode (CPU firmware) updates, claiming these "are not new speculation-based attacks," a statement that the research team disagrees with.
The two new attacks target a feature of AMD CPUs known as the L1D cache way predictor. Introduced in AMD processors in 2011 with the Bulldozer microarchitecture, the L1D cache way predictor is a performance-centric feature that reduces power consumption by improving the way the CPU handles cached data inside its memory. A high-level explanation is available below: "The predictor computes a uTag using an undocumented hash function on the virtual address. This uTag is used to look up the L1D cache way in a prediction table. Hence, the CPU has to compare the cache tag in only oneway instead of all possible ways, reducing the power consumption." The two new attacks were discovered after a team of six academics [...] reverse-engineered this "undocumented hashing function" that AMD processors were using to handle uTag entries inside the L1D cache way predictor mechanism. Knowing these functions, allowed the researchers to recreate a map of what was going on inside the L1D cache way predictor and probe if the mechanism was leaking data or clues about what that data may be. While the attacks can be patched, AMD denies that these two new attacks are a concern, claiming they "are not new speculation-based attacks" and that they should be mitigated through previous patches for speculative execution side channel vulnerabilities.
The research team says AMD's response is "rather misleading," and that the attacks still work on fully-updated operating systems, firmware, and software even today.
The two new attacks target a feature of AMD CPUs known as the L1D cache way predictor. Introduced in AMD processors in 2011 with the Bulldozer microarchitecture, the L1D cache way predictor is a performance-centric feature that reduces power consumption by improving the way the CPU handles cached data inside its memory. A high-level explanation is available below: "The predictor computes a uTag using an undocumented hash function on the virtual address. This uTag is used to look up the L1D cache way in a prediction table. Hence, the CPU has to compare the cache tag in only oneway instead of all possible ways, reducing the power consumption." The two new attacks were discovered after a team of six academics [...] reverse-engineered this "undocumented hashing function" that AMD processors were using to handle uTag entries inside the L1D cache way predictor mechanism. Knowing these functions, allowed the researchers to recreate a map of what was going on inside the L1D cache way predictor and probe if the mechanism was leaking data or clues about what that data may be. While the attacks can be patched, AMD denies that these two new attacks are a concern, claiming they "are not new speculation-based attacks" and that they should be mitigated through previous patches for speculative execution side channel vulnerabilities.
The research team says AMD's response is "rather misleading," and that the attacks still work on fully-updated operating systems, firmware, and software even today.
"AMD believes these are not new" (Score:5, Interesting)
> AMD believes these are not new speculation-based attacks.
I skimmed the PDF and I don't see a link to a github or anything.
Did the researchers give a copy of the code to AMD? It doesn't matter what anybody "believes". The only way AMD should say something like that is if they read the paper and the researchers didn't give them the code and from what the paper says they should be covered.
If the researchers can reproduce the problem on a current stack and AMD can't then something is very wrong. Maybe the researchers are saying "you're AMD and we wrote the paper well enough - you figure it out". That would be a dick move. Maybe the right people at AMD haven't seen it. Something stinks either way.
Researchers used Spectre in the paper (Score:3, Insightful)
According to the paper, the researcher's proof of concept used the new exploit in conjunction with Spectre to get data. So although the exploit may be real and unmitigated in newer OSs, the researchers haven't shown that it can be used by itself to get data.
AMD response is reasonable in this context. I haven't read the paper deeply enough to try to understand if this can be exploited without already patched exploits.
Re:Researchers used Spectre in the paper (Score:5, Interesting)
The paper presents 4 possible uses of the new attack as "Case Studies" in section 5.
According to my understanding of the paper, only one of them ("leaking kernel memory", section 5.3) combines the new attack with Spectre.
That still leaves three "Case Studies" feasible without Spectre:
"Covert Channel" (section 5.1) allows entities to communicate that shouldn't (e.g. communication between two virtual machines on the same host). I guess this is not something most people computers users will worry about a lot. And those who really need separation probably mostly use airgaps rather than virtual machines anyway. Still, might be a building block in other attacks.
Breaking address space layout randomization (section 5.2): Doesn't look dangerous by itself, but defeats an important countermeasure to buffer-overflow attacks, so useful as a building block in other attacks.
"Attacking AES T-Tables" (section 5.4): This one looks like a big deal to me. Sure the case study is about a particular variant of AES. But they were able to recover 99.7% of the bits of an AES key from OpenSSL 1.1.1c, apparently the latest version of OpenSSL at the time of the research (today 1.1.1d is current, I don't see any change since 1.1.1c that looks like it would defeat this attack), in their experiments, which means for all practical purposes, they got the key. And I guess the attack will be used in a similar way in the future to attack further cryptography.
Re: (Score:2)
I wonder if AMD's encrypted RAM would defeat the covert channel one. Each VM has its own RAM encryption key so any data they exchange would be random bits to the other side.
The AES attack is more worrying, although it does of course require executing code on the target.
How many bits are they missing at 99.7%? (Score:2)
If it's 256 bits then they are missing 1 bit? At that point they can try both keys (bit on/bit off).
If it's 1024 bits then they are missing 4 bits? Again, not a lot of remaining combinations.
Even with a 4096 bit key they are only missing 14 bits. Is there something I'm missing?
They have the bits but their bits are in pieces and they don't know what order they go in? Seems very fishy to me.
Re: (Score:3)
Typically, the AES key is exchanged once per session. But you could modify the protocol to exchange a new AES key at certain intervals
A lawyers way of fuzzing the truth (Score:3)
Re: A lawyers way of fuzzing the truth (Score:4, Interesting)
And that is exactly the problem - AMD is refusing to fix and misleading their customers because they are afraid of the results.
In combination with their CPU architecture, these hash tables are what gives AMD a huge boost in their only currently superior benchmarks - multicore integer benchmarks.
Basically by using a fast but poor algorithm they can avoid a ton of overhead - if all data can be trusted. If they have to flush (which means reading from memory), the Achilles heel of the new AMD architectures becomes noticeable, low bandwidth interconnects and in their first two generations, that means core hops to memory which would make ~half the cores useless for multiprocess and even many multithreaded workloads.
If this is confirmed and the only fix is to flush caches like the Intel machines, AMD is back to square one on the server market.
Re: (Score:2)
Re: (Score:1)
An Intel funded "researches" team "discovers new vulnerability" that is mitigated as (AMD has commented upon request from tomshardware) part of the mitigation to Spectre.
What did I miss here? Ah, the 3 large letters, D, U and F.
Re: (Score:2)
Re: (Score:1)
Prove It (Score:5, Insightful)
If this attack is actually a threat, the researchers should have the code to demonstrate it in action. If AMD is right that previous speculative fetch upgrades have already fixed this, the same code should demonstrate that. Without code, the PDF paper itself is just speculation.
Re:Prove It (Score:5, Insightful)
If this attack is actually a threat
If *any* speculative execution attacks were actually a threat then we'd all be owned by hackers by now given the high profile of machines using Intel chips and the complete inability for most to successfully patch the exploit.
Re: (Score:2)
You're ignoring that previous speculative execution attacks had PoCs.
Re: (Score:3)
Nope. Having a PoC and a vulnerability being a "threat" are two different things. You can generate a lot of PoCs when you have full control of the PC you're on. That's my point. All of these vulnerabilities are not a "threat" to most people as to do anything practical with them one needs to have unfettered access to a system.
Re: (Score:2)
And when they won't even produce a PoC? What then?
Re: (Score:2)
Re: Prove It (Score:1)
Re: (Score:3)
If they published the code in the paper, that would just feed the script-kiddies. By only describing the method, it does at least require some knowledge, talent and effort on the coder.
The authors claimed that the vulnerability had been disclosed to AMD in August last year. AMD has probably seen the code, and if their experts didn't believe that the exploit was possible, they would most likely denounce the paper as false. And the authors would not ruin their reputation if they believed that to be likely.
Mos
Re: (Score:3)
Intel only paid the first instalment to the researchers, so you get the paper without code. When the second payment is made, then we'll see the code.
Complexity (Score:4, Interesting)
Pretty soon you'll be able to order different SKUs for the same processor; one will enforce strict boundaries for everything, the other one will be 10x as fast while potentially giving access to your data in order to optimize calculations per second/watt.
Re: Complexity (Score:5, Interesting)
It actually wouldnâ(TM)t necessarily be a terrible idea, especially if both were embedded in the same chip. You could hypothetically run the OS on the slow cores, and have it choose tasks to be put onto faster cores, you then carefully control which processes memory are allowed to be put in cache on the fast cores, and make all syscalls have to run on the security conscious cores, and take a predictable amount of time.
Re: (Score:2)
Three cheers for prior art!
Re: Complexity (Score:2)
Egress control and gating is the future of network security. All gateways should do much more traffic monitoring. Security appliances should be mainstream consumer devices on most home networks. And yet few are offered. Are the powers that be too enamored with porous boundaries?
Re: (Score:3)
Is anyone else of the opinion that we're reaching some point where the added complexity to gain performance increases in processors (and probably other technology, too) is hitting some tipping point where it's not possible to have both performance increases and security?
It's basically too costly to make a faster processor and do enough in-depth study to find and fix security problems that also don't sacrifice the performance gains.
Maybe in some military circumstance you can have have it, but its not economi
just saying (Score:2)
Anyway, if true I hope AMD will come up with a microcode patch soon, I have several systems that would be affected.
Re: just saying (Score:2)
Re: (Score:2)
Re: (Score:2)
And it doesn't fucking matter in the least if the vulnerability exists, and AMD has had over 6 months to do something about it and hasn't.
Now if it was some made up bullshit, or a very minor thing being turned into a giant thing by Intel money, that's one thing. This seems to be another - a legit vulnerability that AMD seems to disagree that they need to fix. That's a problem.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Intel-Funded Study Finds AMD Processors Including All Ryzen Chips Vulnerable To Side-Channel Security Flaw
https://hothardware.com/news/amd-processors-past-decade-zen-vulnerable-side-channel-attack
Re: (Score:2)
Except if the research found real vulnerabilities, who gives a fuck who paid for it?
It's not like these researchers created the vulnerability - AMD did that, years ago. The finding of it 6 months ago by these guys, regardless of funding source, is a good thing. Now AMD needs to do something about it, which they are refusing to do so far, which is a bad thing.
Intel might act like fuckwads a lot of the time (and they do) but this is not one of those times. AMD needs to own it and fix it. Hopefully better
Re: just saying (Score:2)
Re: (Score:3)
I'm not saying the claim is true or false, but I do wonder how much money Intel has paid to have someone, anyone, find some kind of flaw with CPUs of AMD...
There is no indication that Intel specifically paid them to find a flaw in an AMD processor.
But if you want to know how much Intel contributed to this research: Funding for one grad student, who is one of the authors of the paper.
Anyway, if true I hope AMD will come up with a microcode patch soon, I have several systems that would be affected.
At this point, I see no reason to assume this not to be true. The authors are experienced in their field, and have a track record: They are the people who discovered Spectre and Meltdown.
Re: just saying (Score:1)
At this point, I see no reason to assume this not to be true.
In other [more honest] words, you see no reason not to assume.
Sleazy fuck.
Re: (Score:2)
I see a reason... There's no code. Where is the PoC code?
Show me the code!
Re: (Score:1)
Re: (Score:2)
So what? AMD's secrecy somehow trumps our need to know? Bullshit.
Re: (Score:2)
Who cares who paid to find the vulnerability? It's a vulnerability in a decade of products that the manufacturer is not fixing.
I don't give a shit who funded the research, as long as it's valid research. AMD needs to fix it, just the same as Intel needs to fix theirs.
Re: (Score:3)
Re: just saying (Score:2)
The reason for that is, Intel should be working on fixing their problems. Instead, it seems that they are downplaying their own product's shortcomings, and working on getting a position to be pointing at the competition and going, look, same problem there.
If successful, that will lead to lesser efforts to actually fix things.
Don't forget that the pressure to have things fixed depends strongly on the bottom line, if there'
Wonders (Score:2)
Comment removed (Score:4, Interesting)
Re: (Score:2, Insightful)
Re:I'll get hate but... (Score:4, Insightful)
Either these guys are really shit at their jobs and don't know what SOP procedure is for vulnerabilities or its another "There is a risk, click my clickbait but I won't tell you what it is ZOMFG!". If they got a vulnerability? Lets see it so we can see how dangerous it truly is. I mean if it requires local access? Don't care, if they already have hands on keyboard and chair I got bigger issues. If it can be pwned with Javascript? Then we need to know about it and take steps, so show us the code already!
These are the same people that found Meltdown and Spectre.
Just because on of their grad students (who is a coauthor on this paper) gets money from a grant from Intel doesn't mean their results are invalid whenever they look at non-Intel processors.
Comment removed (Score:4, Insightful)
Re: (Score:1)
AMD probably has it's own set of different security flaws, and in the past security researchers would have looked at the most common CPUs, (many of which are made by Intel). So perhaps it's time for more AMD only exploits to be found.
But I can't shake the feeling that this particular report is either about immediate money, (like that stock market scam against AMD a few years ago). Or, it is about future money, to s
Re: (Score:2)
In the automobile industry (Score:2)
The vehicle would be subject to a recall. It is up to the manufacturer to provide a repair or replace the defective part.
That should be required for chip manufactures as well.
Re: (Score:2)
Not even close. That would mean that every vehicle that doesn't have a 5-star safety rating would be recalled. Doesn't happen. Cars are recalled for only a few reasons:
1) Business decision - fixing a problem with a recall will save on warranty costs later
2) Business decision - fixing a problem that could cause reputational harm that is likely to materially affect the company
3) Mandated - only in cases where a problem CAUSES actual accidents (or makes the accident more severe)
4) Mandated - where some regu
Didn't impress me (Score:4, Insightful)
So they deduced the hash algorithm used in a power saving optimization which at most can leak (by itself) a statistic hit rate combined with a hashed address. AMD does one lookup to one way (place where data can be stored in a set-associative cache) and only tests the other ways if the first one is a cache miss, this is a power optimization and while it (as all types of caching) is speculative it isn't of the same type as the speculative attacks.
Again this in itself doesn't impress me much and AMD's response seems reasonable.
Intel Sponsorship (Score:2)
The research was sponsored by Intel, oh, how desperate they are;
https://hothardware.com/news/a... [hothardware.com]
Re: (Score:2)
A processor company funding some positions in computer architecture or a related field is not exactly surprising.
Yes, one of the authors, a grad student, gets Intel grant money. That doesn't mean that the vulnerability the authors found is not a vulnerability.
Re: (Score:2)
true, but AMD says the vulnerability is not new and is the same older known vulnerability.
Re: (Score:2)
No it is not.
https://mlq.me/download/takeaway.pdf [mlq.me]
From the Acknowledgments:
Additional funding was provided by generous gifts from Intel. Any opinions, findings, and conclusions or recommendations expressed in this paper are those of the authors and do not necessarily reflect the views of the funding parties.
Put COmputer (Score:2)
Put Computer in middle of room. If attacker approaches, shoot in head. What the problem?
That's it, I'm switching to ARM (Score:2)
Come on Apple, when are you going to release your new ARM-powered 11" MacBook Air?
It's an Intel ploy! (Score:1)