Live data from Hacker News

More Intel speculative execution vulnerabilities

mdsattacks.com

71–80 of 262 posts

Re: More Intel speculative execution vulnerabilities

#71
post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

Perhaps researchers can use the tested-and-proven "Full Disclosure" tactic to exert public pressure on Intel. It doesn't need to disclose everything, just two or three additional unpatched PoCs with full source code would be enough.

However, unlike buffer overflow exploits, most researches on CPUs are conducted within academic institutions, doing this certainly breaches the code of conduct. Also, CPUs are the most critical components of all computers and their vulnerabilities are difficult to fix, doing this would put a lot of users under immediate risks, unlike a root exploit, which is less risky and can be fixed within a week. Doing Full Disclosure of hardware exploits that users can not fix is much more ethically problematic than software exploits.

But leaving the users in the dark and allowing Intel to delay its fixes by not to exert pressure is obviously irresponsible, which is the original argument for full disclosure.

So I'm not sure. Perhaps Google's Project Zero is a good model and a good compromise between resposible/full disclosure - embargo for 90 days, full disclosure later, all information becomes public after 90 days and no extension is allowed, period. For CPUs, perhaps we can use 180 days.

Re: More Intel speculative execution vulnerabilities

#72
post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

I wonder if it might not come to bite them though. Doing it this way means that the media will constantly keep talking about yet another vulnerability in Intel CPUs for years. There's a chance that Intel might and up picking a reputation like Flash did for being insecure.

Or like java applet. Oracle has killed java applet by not handling security issues in a responsible manner.

Re: More Intel speculative execution vulnerabilities

#73

Earlier quoted context omitted.

Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.

There have been more Chrome/Firefox 0-days than speculative execution vulnerabilities exploitable in Javascript (0). Sure, there is a chance that the Chrome/Firefox teams missed something, but there have been sighted no exploits since the release (of spectrev1) and the browser fixes. It's not a crazy threat model to have on a personal PC, the risk is so very minimal. If your threat model is that strict you shouldn't…

Browser 0-days still often run on user priviledges. The moment you get code-execution on a vulnerable Intel CPU that turns into hardware level access.

And like the other commenter said, there are also JS implementations.

Re: More Intel speculative execution vulnerabilities

#74

AMD is suffering much less from these flaws. Seems they didn't ignore as many security boundaries with their implementation.

There are some architectural differences that help amd with this specific issues, but I’m pretty sure main reason is just scale - amd is still niche nowadays and receives much less scrutiny and attention from security researchers

Re: More Intel speculative execution vulnerabilities

#75
post #61

Earlier quoted context omitted.

HP was the Google of its day when H & P were in charge. People either retire or die eventually. What happens to Google when time claims Larry and/or Sergei? Not trying to besmirch or minimize early HP by comparing to Google -- probably better to use Musk/SpaceX or something -- but IMO this is the key takeaway that doesn't seem widely discussed. Innovative companies have innovative leaders with expert-level knowledge…

What about companies like IBM? The company was originally foundered in 1911, but you could say their heyday wasn't until half a century later (or even more), after the original founder had left.

Not saying this happened at IBM, but sometimes correct people can be promoted into correct positions, in which case the company keeps going just fine.

However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business.

It seems like the death of a company is inevitable.

Re: More Intel speculative execution vulnerabilities

#76
post #61

Earlier quoted context omitted.

What about companies like IBM? The company was originally foundered in 1911, but you could say their heyday wasn't until half a century later (or even more), after the original founder had left.

Not saying this happened at IBM, but sometimes correct people can be promoted into correct positions, in which case the company keeps going just fine. However, at some point any company is probably bound to promote wrong people, who will end up promoting/hiring the wrong people under them, eventually completely changing the course of the business. It seems like the death of a company is inevitable.

> It feels like the death of a company is inevitable.

Which, from a higher perspective, is good. As it breaks down monopolies and give way to more innovative new companies.

Re: More Intel speculative execution vulnerabilities

#77
post #58

Earlier quoted context omitted.

The browser mitigation’s only work with the kernel mitigation’s. Neither is working well without the other. And yes. I’m very well versed on this topic.

>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.

The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time.

The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers.

But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand.

You just make these attacks more likely; I'm not going to be impacted except for a few trillion CPU cycles of idiots trying to exploit me.

You're the one who puts their entire digital life on the line by eking out 5% performance.

Re: More Intel speculative execution vulnerabilities

#78

Running the below over my machines gives me back the 8-30% cycles I originally paid for, depending on load type. This will have to do until everything is swapped to AMD. Note you only need 'mitigations=off' in later kernels. - name: Disable CPU-sapping security mitigations become: yes lineinfile: path: /etc/default/grub line: GRUB_CMDLINE_LINUX_DEFAULT="noresume noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off…

Your web browser runs untrusted code. On a computer that never runs untrusted code you can do that.

Not every computer runs a web browser. Of the hundreds of high performance cores I have, only a couple run a web browser. ... thought increasingly more of them are non-intel.

Re: More Intel speculative execution vulnerabilities

#79
post #52

> We are particularly worried about Intel's mitigation plan being PoC-oriented with a complete lack of security engineering and underlying root cause analysis, with minor variations in PoCs leading to new embargoes, and these "new" vulnerabilities remaining unfixed for lengthy periods. Unfortunately, until there is sufficient public / industry pressure, there seems to be little incentive for Intel to change course, l…

Delaying the fixes is probably making them more money, if they lose a few more percent of performance they lose the number one position on all possible use cases/workflows , the PR hit will be huge, people could demand refunds or compensation (I mean you just sold them an expensive product without disclosing it is insecure and it will lose it's performance)

Re: More Intel speculative execution vulnerabilities

#80
post #77

Earlier quoted context omitted.

>The browser mitigation’s only work with the kernel mitigation’s. That's just not true. The timer precision doesn't have anything to do with the kernel mitigations.

The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time. The browser vendors themselves said this; and it's not a permanent solution as tech such as Stadia and WebVR rely on high precision timers. But, whatever man, I'm telling you that it's stupid and you want to bury your head in the sand. You just make these attacks more likely; I'm not going to be impacted…

>The timing precision thing by itself doesn't twarte anything, it just makes the attacks harder or take more time.

Oh, so it just takes more time, so you have knowledge of an exploit? Fine, show me any PoC or similar bypassing the lower accuracy and site isolation.

You are such a big part of the problem with how this whole class of exploits have been handled. No technical knowledge, just spewing stuff like "You're the one who puts their entire digital life on the line", when we there is no indication that anything like that can transpire.

Please stop spreading misinformation.

Post reply on HN