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

#51
lexluthermiester
KarymidoN
probab just having fun, he realeased a full video demo later explaining in very technical and acurate data his findings

Yup, freaky.
Posted on Reply
#52
timta2
btarunr
At this point I think the only way Intel can fight these vulnerability discoveries is by killing the bug bounty program, or significantly reducing the bounty. The program has clearly sprung up a cottage industry of security researchers (uni professors and their college grad minions) bruteforcing Intel processors for vulnerabilities that they can write papers on (earn citations), report back to Intel, and claim the cash bounties. The BBP has become a fountainhead of headache for CTOs and CIOs.

AMD is safer only because its market footprint is too small in the datacenter space, most of these side-channel attacks affect datacenters, and you can't hack AMD processors for rich bounties (it's similar to the "Macs don't get viruses" fallacy of the 1990s and 2000s).
Shouldn't you be backing up statements like this with a reputable source you can cite, to prove this was a "fallacy"? The truth is that there's always been very little Mac malware in the wild, and all of current Mac malware, that I'm aware of, requires physical access and/or for the user to enter their password and install it themselves. As a Mac enthusiast since 1985, the only Mac "malware" I've ever seen in the real world was a Microsoft Word Macro virus.

This also seems like an unrelated and inappropriate dig.
Posted on Reply
#54
R-T-B
btarunr
At this point I think the only way Intel can fight these vulnerability discoveries is by killing the bug bounty program, or significantly reducing the bounty. The program has clearly sprung up a cottage industry of security researchers (uni professors and their college grad minions) bruteforcing Intel processors for vulnerabilities that they can write papers on (earn citations), report back to Intel, and claim the cash bounties. The BBP has become a fountainhead of headache for CTOs and CIOs.
Ha, no.
Posted on Reply
#55
hat
Enthusiast
Geez, guys. I'm all for a healthy debate, don't get me wrong... but do realize BTA is allowed to have an opinion, the same as anyone else.
Posted on Reply
#56
mtcn77
The playing field isn't even is all we are saying. It is the complete marvel universe vs. thanos, oh wait, what did I just say, snap! Melodramatic much...
It isn't btarunr's fault, even. We are grimy over puns such as these:
AMD CPUs are vulnerable to a severe new side-channel attack"Finally, an issue with AMD CPUs!" - someone at Intel probably
I like this sort of thing, just my sort of zero risk bias. However, just look at what the focus is on:
AMD CPUs are vulnerable to a severe new side-channel attack
The gaslight is just too intense here. Either sarcastic for noninvolved, or overly dramatic for involved parties, there is just no redeeming quality of such shitty captioning.
That is what we should assemble against, imo.
Posted on Reply
#57
R-T-B
hat
Geez, guys. I'm all for a healthy debate, don't get me wrong... but do realize BTA is allowed to have an opinion, the same as anyone else.
I know, he is. I just disagree completely with it's foundations on the level I would a flat-earther.

But yes, he is.

Vya Domus
There is something bewildering about the way these things are made public
Sensationalism sells, applies here as well as the media. Is it profesional? No. Does that stop anyone? No.

Ferrum Master
That kernel.org documentation conflicts with Microsoft published info. Who's telling the truth then?
Both? One applies to linux, and the other windows? You do realize kernel.org parameters are for the linux kernel and not the MS one, right?

btarunr
Name a ransomware that leverages a CPU-level vulnerability. Bonus points for one that leverages a side-channel attack vector.
Survivership bias. It only takes one.
Posted on Reply
#58
Ferrum Master
R-T-B
Both? One applies to linux, and the other windows? You do realize kernel.org parameters are for the linux kernel and not the MS one, right?
I read through that later, I didn't get why he replied it that way, I was thinking about the powershell tool also switching mitigations, with the same idea in mind. Win10 doesn't allow to disable Spectre V1, it's baked in. Easy to test... 4K reads writes for my Optane. They crumble a bit with each mitigation. On win7 those are 300MB/s on Win10 those are 170MB/s. Google's retpoline helped a bit for, but still... if this one is promised to be much harder penalty... no good at all.

The other thing is... if a piece of software gets recompiled with worse feature set, having workarounds... it will be slower by definition... Basically... there ain't no good scenario, good ending here.

The idea the bounty program should be accelerated as much they can, to ensure future products don't suffer from it anymore. This generation is tossable for sure.
Posted on Reply
#59
hat
Enthusiast
R-T-B
I know, he is. I just disagree completely with it's foundations on the level I would a flat-earther.

But yes, he is.
And that's fine. I'm just calling out the disproportionally large number of people in the comments doing the same, I suspected just because it's BTA. You don't usually see this amount of people arguing with a single normal forum member... unless they say something really, really dumb.
Posted on Reply
#62
HwGeek
Bad...Very bad...

AMD FX 9590 to Intel 9900K: "I am no longer afraid from you!".
Posted on Reply
#63
mtcn77
HwGeek
Bad...Very bad...

AMD FX 9590 to Intel 9900K: "I am no longer afraid from you!".
We are back in business!
Posted on Reply
#64
John Naylor
Much Ado Bout Nothing -
Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous
https://www.extremetech.com/computing/307433-security-disclosures-on-theoretical-intel-cpu-flaws-are-becoming-ridiculous

"Unfortunately, it’s starting to look like the PR departments working with security researchers the world over have taken a very real problem with problematic leakage of data in side-channel attacks and are now spinning theoretical scenarios that aren’t backed up by the data in the documents themselves. "

In other words, security researchers (or security research firms’ PR divisions) are now putting out reports claiming Intel CPU’s are catastrophically at-risk from theoretical attacks that haven’t even been created yet, even though these attacks are incredibly difficult or downright theoretical. This is an absurdity.
Asking a company to design hardware intelligently to mitigate existing or well-known risks is one thing. Asking it to design hardware that secures against esoteric attacks that haven’t even been demonstrated in real-world testing yet is ridiculous. Even Bitdefender’s Director of Threat Research agrees that this attack isn’t one Intel should realistically bother securing against because it’s so hard to deploy.

We’re starting to hear about ‘theoretical’ risks to both Intel and AMD and threats that could emerge someday, but, you know, don’t actually exist right now. There’s nothing wrong with planning ahead, but given the long development cycles that CPUs go through, there’s no practical way for Intel to build a 2020 CPU to handle every possible security flaw that might be found in software, hardware, or both by 2025. The nature of security flaws is that after you patch one, people go out and find another. I'm increasingly convinced that Intel isn’t being treated fairly by these reports, and it’s not just Intel. Earlier this week we covered another instance where the PR verbiage around an AMD flaw didn’t match what the actual security researchers said in public.

These "security warnings" are akin to "Well we all could fly of the planet .... if we lived in a world w/o gravity."
Posted on Reply
#65
lexluthermiester
John Naylor
Much Ado Bout Nothing -
Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous
https://www.extremetech.com/computing/307433-security-disclosures-on-theoretical-intel-cpu-flaws-are-becoming-ridiculous

"Unfortunately, it’s starting to look like the PR departments working with security researchers the world over have taken a very real problem with problematic leakage of data in side-channel attacks and are now spinning theoretical scenarios that aren’t backed up by the data in the documents themselves. "

In other words, security researchers (or security research firms’ PR divisions) are now putting out reports claiming Intel CPU’s are catastrophically at-risk from theoretical attacks that haven’t even been created yet, even though these attacks are incredibly difficult or downright theoretical. This is an absurdity.
Asking a company to design hardware intelligently to mitigate existing or well-known risks is one thing. Asking it to design hardware that secures against esoteric attacks that haven’t even been demonstrated in real-world testing yet is ridiculous. Even Bitdefender’s Director of Threat Research agrees that this attack isn’t one Intel should realistically bother securing against because it’s so hard to deploy.

We’re starting to hear about ‘theoretical’ risks to both Intel and AMD and threats that could emerge someday, but, you know, don’t actually exist right now. There’s nothing wrong with planning ahead, but given the long development cycles that CPUs go through, there’s no practical way for Intel to build a 2020 CPU to handle every possible security flaw that might be found in software, hardware, or both by 2025. The nature of security flaws is that after you patch one, people go out and find another. I'm increasingly convinced that Intel isn’t being treated fairly by these reports, and it’s not just Intel. Earlier this week we covered another instance where the PR verbiage around an AMD flaw didn’t match what the actual security researchers said in public.

These "security warnings" are akin to "Well we all could fly of the planet .... if we lived in a world w/o gravity."
While that is a good article with many good and valid points, the LVI problem is important to bring to the public eye as mitigations need to be developed for business and enterprise. End users are very unlikely to be affected by this as they have nothing of value to warrant the effort of an attack, but large companies and entities need active protection.
Posted on Reply
#66
R-T-B
HTC
Phoronix tested with Linux and ... it's not good ...
Not as bad as I expected actually. The more practical graph you should be referencing for all but the most secure workloads is the "LFENCE before Ret" one. It's the mitigation that will most likely be used rather than the more extreme ones like "LFENCE + Indirect Branch + RET" which strikes me as overkill and will most likely be made a kernel option.

No one is going to lose 90% of their performance unless they are running a state nuclear program.
Posted on Reply
#67
KarymidoN

your xeon can now be a Celerom Yay
Posted on Reply
#68
R-T-B
KarymidoN

your xeon can now be a Celerom Yay
If you opt for it sure. There is no way that is going to be the default set of Mitigations. You should be looking at LFENCE Before RET as the worst case, LFENCE Before indirect branch as the best.
Posted on Reply
#69
mtcn77
All this probing around accounts for ai generated attacks right? It is only difficult because it isn't native for us. Targetting around for memory imprints is detective work and I don't think gerrymandering around the issue would be too difficult for ai once it connects the dots. Literal TAS on the fly. It's hard? -Say no more fam...
Posted on Reply
#70
R-T-B
mtcn77
All this probing around accounts for ai generated attacks right? It is only difficult because it isn't native for us. Targetting around for memory imprints is detective work and I don't think gerrymandering around the issue would be too difficult for ai once it connects the dots. Literal TAS on the fly. It's hard? -Say no more fam...
I really don't even know what you are trying to say to formulate a reply.
Posted on Reply
#71
biffzinker
R-T-B
I really don't even know what you are trying to say to formulate a reply.
Something about it being easier for a AI trained at carrying out these theoretical, and hypothetical exploits in a CPU?
Posted on Reply
#72
R-T-B
biffzinker
Something about it being easier for a AI trained at carrying out these theoretical, and hypothetical exploits in a CPU?
I don't think an AI could figure out these exploits. Too situational, requiring human interaction and response.
Posted on Reply
#73
mtcn77
I'm not the go to guy, but this local member explained it with a text wall and by the look of this I'm only 'half-wrong' which is accurate enough to sum up this exhibit.
This collide+probe load+reload script kinda serves to break ASLR encryption from 28 to 15 bits on most accounts. It might not seem much, but 65K is a lot sooner than 268M through brute forcing. Coupled with that, presuming the way predictor gets decyphered even more, the suspect attack vector as described to me goes as such,
  • 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.
Posted on Reply
#74
R-T-B
mtcn77
ASLR encryption
What the heck is ASLR encryption? You do know ASLR is a randomization technique for addresss space layouts and doesn't have anything to do with encryption really, right?
Posted on Reply
#75
mtcn77
R-T-B
What the heck is ASLR encryption? You do know ASLR is a randomization technique for addresss space layouts and doesn't have anything to do with encryption really, right?
Thank you, right as you said I'm not up for correct terminology.
Posted on Reply
Add your own comment