Wednesday, March 11th 2020

Intel Processors Hit with LVI Security Vulnerabilities, Mitigation Hits Performance Hard

A new class of security vulnerabilities affect Intel processors, which can cause them to leak out sensitive information if probed in a certain way, but that's not the worst news for Intel and its users. The software- or firmware-level mitigation for this vulnerability can inflict performance reductions "ranging from 2x to 19x," according to a report by The Register. A full mitigation for the new Load Value Injection (LVI) class of vulnerabilities requires Intel to redesign software compilers. The vulnerability is chronicled under CVE-2020-0551 and Intel-SA-00334. It is not a remote code execution threat, however, it puts multi-tenant machines, such as physical servers handling multiple tenants via virtual servers.

"LVI turns previous data extraction attacks around, like Meltdown, Foreshadow, ZombieLoad, RIDL and Fallout, and defeats all existing mitigations. Instead of directly leaking data from the victim to the attacker, we proceed in the opposite direction: we smuggle — "inject" — the attacker's data through hidden processor buffers into a victim program and hijack transient execution to acquire sensitive information, such as the victim's fingerprints or passwords," the reasearchers write in the abstract of their paper describing the vulnerability. Anti-virus manufacturer BitDefender independently discovered LVI and shared its study with Intel. The company could publish its findings in February. Additional technical details are found in the group's website here.
Many Thanks to biffzinker for the tip. Source: The Register
Add your own comment

89 Comments on Intel Processors Hit with LVI Security Vulnerabilities, Mitigation Hits Performance Hard

#76
Aquinus
Resident Wat-man
mtcn77
Thank you, right as you said I'm not up for correct terminology.
I think @R-T-B's point is that If you're not getting the termanology right, what is supposed to make us think that you actually understand the problem correctly? So let's go through the steps you described:
mtcn77
  • We identify targets beforehand(this vulnerability is only the tool, not the means),
  • We spoof memory,
  • We disable cpu caching,
  • We flush caches,
  • We access memory first(this is very important to pull it off without concurrent programs reaching for their turn of memory),
  • We pull spoofed memory which goes to L3,
  • Our accessed memory is in the next sector, however collide+probe somehow makes the sectors enter "probe from access-violate next sector" which is in the next L3 page/word/tag(I haven't figured that part),
  • Through magic voila we now have data that is 2^-15 the data we need.

1. Unless you have root access to the machine, you're not going to know where the data your looking for is. So I don't understand how this is a realistic step in a real attack. You also need to know that this memory isn't going to change or move, so there are a lot of baked in assumptions here.
2. What the heck is "spoofing memory"? Are you overwriting memory for something else? Don't you at least need root access to the machine to do that? Something like this would require ring-0 access on the VM host (not even ring -1 access from a VM,) to do something like that across bounds of a VM.
3. Ok, but do you have control to do that from a VM?
4. Ok, but still not sure if you can do this from a VM.
5. How do you plan on preventing that from happening? If it's a server, that's out of your control.
6. Once again, what is this "spoofing" you speak of? Writing to cache has the same kinds of constraints as writing to main memory and you're probably not doing this without ring 0 access.
7. What are you doing that forces the CPU to read from the next page page, word, or tag in cache? An access violation shouldn't scan for another item in cache, it should generate a machine check exception.
8. :wtf:
Posted on Reply
#77
lexluthermiester
Aquinus
I think @R-T-B's point is that If you're not getting the terminology right, what is supposed to make us think that you actually understand the problem correctly?
This sums it up. It's why I didn't respond. He doesn't seem to understand the context of the documentation, nor the practical application of the functionality of the construct of the proposed attack scenario. However, I'll give him credit for trying to understand it as he's putting in way too much effort to be trolling.
Posted on Reply
#78
mtcn77
The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...
Posted on Reply
#79
lexluthermiester
mtcn77
The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...
AMD is completely unaffected by this new problem. The addressing system works a different way with everything AMD has made in the last 12 years. This is exclusively about Intel. At least that's what the data and documentation says.
Posted on Reply
#80
Aquinus
Resident Wat-man
mtcn77
The part that I might have missed is this gentleman was speaking about Intel and told it right away that AMD was too contained with the addition of page attribution tables in zen+ generation. He kept on going at a spectre deliberation, but I couldn't delineate the two. Anyway, you word as good as mine, folks...
Sure, but even with hardware vulnerabilities, their usefulness has to be measured in practicality. Spectre is a great example of a vulnerability that has almost zero usefulness beyond an academic paper.
Posted on Reply
#81
mtcn77
Aquinus
Sure, but even with hardware vulnerabilities, their usefulness has to be measured in practicality. Spectre is a great example of a vulnerability that has almost zero usefulness beyond an academic paper.
I would advocate the contrary - meltdown is the more lethal vulnerability, but the easiest to patch. Spectre is different which makes it the benchmark vulnerability for this reason.

lexluthermiester
AMD is completely unaffected by this new problem. The addressing system works a different way with everything AMD has made in the last 12 years. This is exclusively about Intel. At least that's what the data and documentation says.
I was transposing the commentary present for AMD to this argument. Have some sympathy! :)

We should still keep comparing the two in my opinion cause lvi, as stated before, is pretty much theoretical only. It is a duel between amd spectre and intel spectre-class vulnerabilities.
Posted on Reply
#82
R-T-B
lexluthermiester
AMD is completely unaffected by this new problem.
As far as we know. The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.
Posted on Reply
#83
mtcn77
R-T-B
As far as we know. The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.
They state even in the white paper that you need meltdown for starters.
Posted on Reply
#84
HTC
mtcn77
They state even in the white paper that you need meltdown for starters.
If true, then AMD cannot be affected by this particular vulnerability.
Posted on Reply
#85
R-T-B
mtcn77
They state even in the white paper that you need meltdown for starters.
You are correct. Mental failure, lol.

HTC
If true, then AMD cannot be affected by this particular vulnerability.
Right.
Posted on Reply
#86
lexluthermiester
R-T-B
The docs are careful to state that AMD very well could and maybe even SHOULD be affected by this, they just could not make it happen in practice.
While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.

HTC
If true, then AMD cannot be affected by this particular vulnerability.
And then there's this.
Posted on Reply
#87
R-T-B
lexluthermiester
While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.


And then there's this.
As I admitted, I needed more caffiene/had a brain fart. Somehow got it confused with Spectre briefly.
Posted on Reply
#88
londiste
lexluthermiester
While I'll admit my understanding of how L1/L2/L3 cache actually functions is limited, what I do know strongly suggests that Intel's and AMD's implementations differ enough that a vulnerability for one can not be assumed for the other.
Not just caches, the microarchitectural implementation (and resulting behaviour) of various buffers that are attacked in recent vulnerabilities are different.
Meltdown in particular seems to be a straightforward bug in Intel's design. One that is complex to abuse but still a bug.
Posted on Reply
#89
mtcn77
londiste
Not just caches, the microarchitectural implementation (and resulting behaviour) of various buffers that are attacked in recent vulnerabilities are different.
Meltdown in particular seems to be a straightforward bug in Intel's design. One that is complex to abuse but still a bug.
Well, the explanation I've got from the expert is that this type of attack has no vector on AMD just because the PSP security processor does not have its own cache to be exploited like SGX.
Posted on Reply
Add your own comment