Meltdown-like vulnerability disclosed for AMD Zen+ and Zen 2 processors

[Daniel Sims]

In brief: AMD along with security researchers at the Dresden Technical University have disclosed a vulnerability in some AMD processors similar to the Meltdown and Spectre vulnerabilities for Intel CPUs that were first disclosed three years ago. AMD has already outlined multiple mitigation techniques to fight these vulnerabilities.

TU Dresden researchers Saidgani Musaev and Christof Fetzer notified AMD of the exploit in Zen+ and Zen 2 processors which they call "Transient Execution of Non-Canonical Accesses," directly comparing them to Spectre and Meltdown. AMD's security bulletin refers to the vulnerability with the name CVE-2020-12965.

AMD says the main risk is that this could cause processors to leak data they aren't supposed to. "When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage," it writes.

Musaev and Fetzer outlined the vulnerability in a research paper. AMD followed this up with its own review which it published on the bulletin. On the same page AMD also has a document outlining its mitigation techniques. "There are a variety of techniques software can use for managing processor speculation, each with different properties and trade-offs," AMD writes.

AMD recommends developers review their code running on the affected processors and insert an LFENCE, or use one of the solutions outlined in the document. AMD says its later and future processors have more security features to defend against these kinds of vulnerabilities like SMEP, SMAP, and IBC.

Meltdown and Spectre are hardware-level flaws for Intel CPUs that were disclosed in 2018 before being patched. If exploited, Meltdown could expose memory that should've been inaccessible, while Spectre could be used to execute malicious code. Patching the vulnerabilities initially caused hits to performance that were eventually mitigated.

In March of last year another vulnerability in Intel processors similarly based on a hardware flaw was found, called Load Value Injection (LVI). Like Meltdown, it can be exploited to leak data that should be protected.

Image credit Technical University of Dresden 

Permalink to story.

https://www.techspot.com/news/91024-meltdown-like-vulnerability-disclosed-amd-zen-zen-2.html

 

[Sausagemeat]

This is positive news for AMD. These vulnerabilities have been wide open the entire time these chips have been on sale. But now that doorway will be closed.

I’m glad that we are finally finding vulnerabilities in Ryzen. be weary of any CPU that has little or no known vulnerabilities. The only reason that happens is when people don’t bother to look for them.

 

[Lionvibez]

"They mention that all Intel processors that are vulnerable to MDS attacks "inherently have the same flaw."

 

[veLa]

When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.

Boy, you are getting into some technical stuff there.

 

[Nobina]

Did anyone ever get hacked using these exploits?

 

[paul1122]

Did anyone ever get hacked using these exploits?

I think my 5900x did by a passive aggressive hacker. The fan spins up every now and then for no apparent reason.

 

[kiwigraeme]

Did anyone ever get hacked using these exploits?

My guess is yes - in highly targeted state sponsored efforts.
As for plebs like us - I haven't heard of anything

Much less effort to social engineer getting money - or have folks deliberately or secretly install your super bitcoin wallet

 

[Bullwinkle M]

Did anyone ever get hacked using these exploits?

Did anyone ever get hacked by a Meltdown-like vulnerability on Intel CPU's?

The point to remember is there were so many AMD cult members putting down Intel and claiming that AMD was immune to any such problems

Let us now give them a moment of silence and allow them to beg forgiveness for their sins

 

[veLa]

Did anyone ever get hacked by a Meltdown-like vulnerability on Intel CPU's?

The point to remember is there were so many AMD cult members putting down Intel and claiming that AMD was immune to any such problems

Let us now give them a moment of silence and allow them to beg forgiveness for their sins

Oh please. Whenever Spectre and Meltdown were discovered, we all knew more vulnerabilities existed and would be exposed for different brands of microprocessors.

 

[Bullwinkle M]

Oh please. Whenever Spectre and Meltdown were discovered, we all knew more vulnerabilities existed and would be exposed for different brands of microprocessors.

"You all" may (or may not) have known more vulnerabilities existed and would be exposed for different brands of microprocessors, but many of "you all" had a very different story 12 months ago

 

[eTheBlack]

I think my 5900x did by a passive aggressive hacker. The fan spins up every now and then for no apparent reason.

Thats just how Ryzen works. Go into bios and set delay to fans, you will be fine after

 

[Avro Arrow]

With these problems showing up on Intel and AMD alike, I have a sinking feeling that this is a problem with the original x86 architecture itself.

 

[jpuroila]

With these problems showing up on Intel and AMD alike, I have a sinking feeling that this is a problem with the original x86 architecture itself.

The problem has nothing to do with x86 - various ARM CPUs have been shown to have similar (and some of the same) vulnerabilities. Rather, the problem is that modern high-performance (relatively speaking) core designs have various out-of-order execution, branch prediction, and other features that were not designed with security in mind.

 

[Markoni35]

With these problems showing up on Intel and AMD alike, I have a sinking feeling that this is a problem with the original x86 architecture itself.

Nope. In the original x86 architecture there was no speculative or out-of-order instruction execution. A CPU would execute each command in the order it was stored in RAM. But with the appearance of multiple execution units, they've concluded "why wouldn't we execute instructions out of order, if they don't influence each other's results". Which makes sense, because then all the execution units are busy, not waiting for some other unit to finish its task.

Of course, this out-of-order execution stops after the conditional jump instruction (same as IF THEN ELSE in programming languages). Because now you don't know whether to execute instruction below THEN or below ELSE. It depends on the condition in the IF, which means it depends on other instructions.

So, what they did? They decided to add a special statistics module, which will help decide whether it's more likely for THEN part to execute or ELSE part to execute. Based on previous executions. It also analyzes loops (which are also conditional jumps).

This improved performance. The CPU was now speculating which way the program will execute, before it even comes to the IF instruction. So, it's speculative execution. Not only it executes commands upfront (this was already present in older CPUs) but it also statistically analyses instructions in real-time. Very cool.

But then they created a big problem. When an instruction for reading data from RAM normally executes, the address of the RAM location is checked. The app may only access the memory allocated to it. Not to RAM belonging to other apps. If the program tries to access RAM that wasn't assigned to it, the CPU will make a hardware interrupt, notifying Operating System that someone is breaking the rules. And OS will report the error to user. That's what happens when you see error message "Memory access violation" during execution of some programs.

One process is not allowed to read RAM belonging to another process. Or even worse, RAM belonging to OS protected data.

But.... and it's a big BUT... they failed to implement this check during speculative execution. So, an instruction reading RAM out-of-order can actually read any location in the entire RAM. That sounds bad, but initially it wasn't so bad. The boundary-check is performed later, when the instruction's regular turn to execute comes. So, there is checking, but not immediately. If the instruction wouldn't even be executed, its result is rejected. So, everything seems okay for now.

But, modern processors also have cache. Which wasn't the part of original x86 architecture either. And cache is great (Talibans would probably say "Cache Akbar") because it makes things faster. But this benefit also makes it possible to exploit that uncontrolled RAM read in the previous step.

Because even though the result of the rejected speculative instruction is... rejected... it still makes a little change in the CPU. The read data from RAM is now in cache. And it's still not directly available to the malicious process. It can't directly read cache. But it can determine that certain parts of RAM are loading faster than others (thanks to cache), so by first preparing the cache (cleaning it) and then speculatively reading the data, and then using a special address instruction, and analyzing data-access timing differences they can determine the value of a byte belonging to another process, including OS.

By repeating this many times, they can (pretty slowly) read any amount of data from any location in RAM.

The only part of x86 architecture that is "guilty" is that special memory addressing instruction at the end. But removing it would kill a zillion apps, as it's used everywhere. And it's not its fault either. The fault was in allowing the speculative instructions to access RAM without consulting the boundary-checking mechanism WHICH IS ALREADY THERE.

Of course....... that fix could cause problems in rare cases when the previous instruction changes boundaries (so, only OS can do it) and out-of-order instruction access which looks illegal now may be legal a few microseconds later. But I think this could be easily mitigated in RAM allocation module with almost zero performance impact.

That was a short explanation what's going on in side-channel attacks of this type.

 

[Avro Arrow]

The problem has nothing to do with x86 - various ARM CPUs have been shown to have similar (and some of the same) vulnerabilities. Rather, the problem is that modern high-performance (relatively speaking) core designs have various out-of-order execution, branch prediction, and other features that were not designed with security in mind.

Well that sure doesn't make me feel better. I guess we're screwed no matter what.