Yet another Intel CPU security vulnerability!

[Rroff]

I'm starting to wonder what useful service these researchers are providing, because if it wasn't for them, would any of this stuff actually be known or useful to anybody? Sure, someone might figure it out on their own, but apart from spies or engineers, who has that kind of expertise? If they're killing my FPS for their willy waving, I'm not amused.

Problem is once these issues start to come to light others will be able to develop them further (standing on the shoulders of giants so to speak). Realistically though unless you've made yourself the target of spies or engineers these vulnerabilities are exceedingly difficult to use in any kind of practical way against every day targets without already having one leg through your security perimeter so if they are you already have bigger security issues to worry about. The real threat is in environments where people already have a foot in the door in unprivileged space such as enterprise systems and other multi-user environments.

 

[jigger]

I'm starting to wonder what useful service these researchers are providing, because if it wasn't for them, would any of this stuff actually be known or useful to anybody? Sure, someone might figure it out on their own, but apart from spies or engineers, who has that kind of expertise? If they're killing my FPS for their willy waving, I'm not amused.

Yes it’s very much critical in today’s world.

 

[IT Troll]

Sounds like SGX is the main concern again. When I last looked (during the Plundervolt discovery) the only desktop app I could find that used SGX was PowerDVD when playing Blu-ray 4K UHD. SGX is used more extensively in virtualised cloud computing though.

I note the research was part funded by gifts from AMD. But it would be foolish to read anything into that.

 

[humbug]

Sounds like SGX is the main concern again. When I last looked (during the Plundervolt discovery) the only desktop app I could find that used SGX was PowerDVD when playing Blu-ray 4K UHD. SGX is used more extensively in virtualised cloud computing though.

I note the research was part funded by gifts from AMD. But it would be foolish to read anything into that.

I wouldn't trust it if i was you...

 

[chrcoluk]

I'm starting to wonder what useful service these researchers are providing, because if it wasn't for them, would any of this stuff actually be known or useful to anybody? Sure, someone might figure it out on their own, but apart from spies or engineers, who has that kind of expertise? If they're killing my FPS for their willy waving, I'm not amused.

Thats been my issue from the beginning.

The proper way to deal with this stuff is in my opinion.

1 - Dont publically disclose.
2 - Inform the vendor.
3 - Vendor makes patches but if patches have a negative consequence, do not deploy unless is known for the issue to be out in the wild, so its a kind of been ready for it.
4 - Only go public if its already been actively exploited "and" vendor doesnt respond.

Killing performance for security issues that were not been exploited and were likely not known seems nonsensical, in addition these are all now known, so bad guys are been given free knowledge.

 

[NinjaCool]

LVI - Hijacking Transient Execution with Load Value Injection

https://lviattack.eu

It seems this new attack is particularly devastating in multi tenant environments such as enterprise workstations and cloud servers in datacenters.

https://thehackernews.com/2020/03/intel-load-value-injection.html
"Since the hardware flaws cannot be eradicated with software patches and flushing affected buffers are no longer sufficient, researchers suggest affected users to either disable rich performance features like hyper-threading, or replace the hardware to completely avoid such vulnerabilities" Ouch!

 

[Rroff]

Thats been my issue from the beginning.

The proper way to deal with this stuff is in my opinion.

1 - Dont publically disclose.
2 - Inform the vendor.
3 - Vendor makes patches but if patches have a negative consequence, do not deploy unless is known for the issue to be out in the wild, so its a kind of been ready for it.
4 - Only go public if its already been actively exploited "and" vendor doesnt respond.

Killing performance for security issues that were not been exploited and were likely not known seems nonsensical, in addition these are all now known, so bad guys are been given free knowledge.

Problem is that things like increased compute power, machine learning and more and more advances in maths, etc. make some of these vulnerabilities more and more feasible to discover (or do anything remotely useful with). People talk about Intel taking shortcuts, etc. but in a lot of these cases these are really obscure, very difficult to foresee as being breakable 1-3 decades back when a lot of this stuff was being designed - although Intel have no excuse for not taking security researchers seriously and stop trotting out the same reused architecture(s) in more recent years when they started to discover these kind of techniques and how to manipulate them which has been vastly advanced in the last few years by the advances in some of the things I mentioned to actually factor them out.

There is a small side story there with the specific nature of some of these and how hard they "should" be to discover/exploit by accident that might point to them being intentionally left in weaknesses for covert use but that would be hugely speculation.

 

[IT Troll]

If home users are concerned they can disable SGX in BIOS with no loss of performance and in most cases no loss of functionality. Non-server systems will typically have SGX set to Disabled or Software Controlled by default, rather than Enabled.

 

[CHokKA]

Sounds like SGX is the main concern again. When I last looked (during the Plundervolt discovery) the only desktop app I could find that used SGX was PowerDVD when playing Blu-ray 4K UHD. SGX is used more extensively in virtualised cloud computing though.

I note the research was part funded by gifts from AMD. But it would be foolish to read anything into that.

Be upfront and quote that along with AMD, Intel and ARM also did the same, rather than trying to sensationalise things further.

Things are looking more and more brutal for Intel at the moment. I wonder how they're going to weather all of this, along with their latest statement that their new tech will likely be less profitable than their 22nm and that they're not going to be competitive until at least 2021?

 

[IT Troll]

Be upfront and quote that along with AMD, Intel and ARM also did the same, rather than trying to sensationalise things further.

Hence the winky face. It was a reference to the "Intel-Funded Study Finds AMD Processors Including All Ryzen Chips Vulnerable To Side-Channel Security Flaw" headlines we saw just the other day.

 

[jigger]

LVI - Hijacking Transient Execution with Load Value Injection

https://lviattack.eu

It seems this new attack is particularly devastating in multi tenant environments such as enterprise workstations and cloud servers in datacenters.

https://thehackernews.com/2020/03/intel-load-value-injection.html
"Since the hardware flaws cannot be eradicated with software patches and flushing affected buffers are no longer sufficient, researchers suggest affected users to either disable rich performance features like hyper-threading, or replace the hardware to completely avoid such vulnerabilities" Ouch!

Yeah it’s a shocking flaw. Intel are in deep water.

 

[alec]

The faults are real and need to be fixed, whoever finds them (as long as published via proper channels) or funds them.
But the amount of noise they generate "oh noes 50% performance reduction, Intel is toast" vs "affects only SGX tasks in a few corner cases, meh, nobody should care" can definitely be skewed to one or other side.

 

[EsaT]

Killing performance for security issues that were not been exploited and were likely not known seems nonsensical, in addition these are all now known, so bad guys are been given free knowledge.

"Security through obscurity" is failed concept from the start and relies on assumption that there aren't bad guys looking for ways to open locks.
https://en.wikipedia.org/wiki/Security_through_obscurity

Just look at how well it worked against Coronavirus first in China and now in Europe.
Nothing wrong here... Doesn't concern us...
Yeah, right...

Yeah it’s a shocking flaw. Intel are in deep water.

What water?
It's all their self made urine in which they're now.

 

[jigger]

"Security through obscurity" is failed concept from the start and relies on assumption that there aren't bad guys looking for ways to open locks.
https://en.wikipedia.org/wiki/Security_through_obscurity

Just look at how well it worked against Coronavirus first in China and now in Europe.
Nothing wrong here... Doesn't concern us...
Yeah, right...



What water?
It's all their self made urine in which they're now.

Pretty much.

 

[chrcoluk]

"Security through obscurity" is failed concept from the start and relies on assumption that there aren't bad guys looking for ways to open locks.
https://en.wikipedia.org/wiki/Security_through_obscurity

Just look at how well it worked against Coronavirus first in China and now in Europe.
Nothing wrong here... Doesn't concern us...
Yeah, right...



What water?
It's all their self made urine in which they're now.

I wonder what the basis of calling security via obscurity failure is?

Is it the best way to mitigate attacks? probably no. Is it useless? definitely no.

Effectively is two main types of security via obscurity.

Simple things like changing the port of a service to non default, which prevents automated bots from coming across that scan ip ranges, this tends to be extremely effective in reducing noise from such bots, and has two prime benefits, it keeps logs clean which means you more likely to see something serious in those logs if they occur, and on the off chance one of these bot authors manages to discover a unpatched vulnerability, you would be saved by the fact they wont come across your service as they will simply think no service is running. Now this would fail if your machine was port scanned, but now days this is less common than you think and probably will only happen if you are specifically targeted. IP scanning on specific ports is way more common than port scanning on a single target.

Another type is of course by not disclosing vulnerabilities to the public, to call this useless makes no sense, if you disclose a vulnerability to an attacker, of which they previously did not know, its effectively teaching them how to start locking pick some types of locks, that's the way I would describe it. I think people claim security via obscurity is useless simply because it has become fashionable to say it, a bit like the "keep software up to date" mantra.

Do we get publications every time someone discovers lets say a way to breach a yale lock, or a bank safe, lets make it public as its the right thing to do? Maybe we should make it public how to clone credit cards, and hack ATM's. I hope you get my point.

 

[Orange Nexus]

I wonder what the basis of calling security via obscurity failure is?

Is it the best way to mitigate attacks? probably no. Is it useless? definitely no.

Effectively is two main types of security via obscurity.

Simple things like changing the port of a service to non default, which prevents automated bots from coming across that scan ip ranges, this tends to be extremely effective in reducing noise from such bots, and has two prime benefits, it keeps logs clean which means you more likely to see something serious in those logs if they occur, and on the off chance one of these bot authors manages to discover a unpatched vulnerability, you would be saved by the fact they wont come across your service as they will simply think no service is running. Now this would fail if your machine was port scanned, but now days this is less common than you think and probably will only happen if you are specifically targeted. IP scanning on specific ports is way more common than port scanning on a single target.

Another type is of course by not disclosing vulnerabilities to the public, to call this useless makes no sense, if you disclose a vulnerability to an attacker, of which they previously did not know, its effectively teaching them how to start locking pick some types of locks, that's the way I would describe it. I think people claim security via obscurity is useless simply because it has become fashionable to say it, a bit like the "keep software up to date" mantra.

Do we get publications every time someone discovers lets say a way to breach a yale lock, or a bank safe, lets make it public as its the right thing to do? Maybe we should make it public how to clone credit cards, and hack ATM's. I hope you get my point.

They have to disclose it so customers like Microsoft and Amazon can take the necessary steps in combating the vulnerabilities on their end. Like some cloud providers disabling Hyper-threading as a deterrent. Researchers who discovered LVI, for example, gave intel almost one year to find a fix for it before disclosing it. Maybe intel was hoping 10 nm will be out by the time everybody finds out.

 

[EsaT]

Another type is of course by not disclosing vulnerabilities to the public, to call this useless makes no sense, if you disclose a vulnerability to an attacker, of which they previously did not know, its effectively teaching them how to start locking pick some types of locks, that's the way I would describe it. I think people claim security via obscurity is useless simply because it has become fashionable to say it, a bit like the "keep software up to date" mantra.

Like it's said in here.

There are no doubt plenty of government sponsored criminals looking into security holes in everything.
At least three countries are pretty darn sure to sponsor those, with two of them having plenty of resources to go this deep.
Would be foolish to assume they aren't looking exactly into these things.

 

[pete910]

Not pretty for the Cloud/Data centre boys

https://www.phoronix.com/scan.php?page=article&item=lvi-attack-perf&num=1

 

[Ice Tea]

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-iGPU-Leak-For-Gen7

Linux 5.7 To Bring Mitigation For Intel Gen7 Ivybridge/Haswell "iGPU Leak"

 

[Ice Tea]

https://www.phoronix.com/scan.php?page=news_item&px=LLVM-SESES-Merged

SESES patch 90% hit to the performance.