Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More Intel speculative execution vulnerabilities

mdsattacks.com

Post reply on HN
Print view View original

41–50 of 262 posts

Re: More Intel speculative execution vulnerabilities

#41

Post by dijit »

scandinavian wrote: post #28
wolf550e wrote: post #23

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…

What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0]

Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution.

Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably the most stupid thing you can do to disable these mitigations because they're not just theoretical, they're real, they're here and everyone knows about them.

This is like anti-vaxx philosophy. "the risk is low"; well, maybe the risk is low because of herd immunity, it's not feasible to run these attacks as they'll be obvious to those who have the mitigations in place (100% CPU), but if there's a 0.00000001% return then it becomes profitable to exploit, just like mail spam.

Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. Unless you can work without javascript and I doubt you can because the web today is basically unusable without it.

If you have a database which is only accessible internally, you can disable the mitigations, because those things are hit hardest by the mitigations and do not run untrusted code.

But really, your desktop is running untrusted code _a lot_. Please do not do this, not only for your own sake but for everyones sake. Don't make it profitable for malicious agents to run these attacks.

[0]: https://www.reddit.com/r/javascript/comments/7ob6a2/spectre_...

Re: More Intel speculative execution vulnerabilities

#42

Post by uwydr »

ageofwant wrote: post #10

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…

You can do the same thing on Windows by using InSpectre: https://www.grc.com/inspectre.htm

Re: More Intel speculative execution vulnerabilities

#43

Post by segfaultbuserr »

wtallis wrote: post #25
Jonnax wrote: post #15

Earlier quoted context omitted.

HP used to be much more. It was a real innovative company. But the interesting parts have been spun out like: Agillent and Keysight. HP Enterprise was also spun out.

Other than splitting off HPE, the HP of 2000 was pretty much the HP of today. As far as I'm aware, they're still major players today in all the markets that they were major players in back then, and none of those HP or HPE business units had to go through a collapse and start over.

Upvoted. Why downvote this comment? It does not have controversial political content nor personal attacks, it's just an OP's personal observation of HP's business performance. If someone disagrees, I'd like to hear you comment (I'm not the OP), rather than letting the comment sink to the bottom.

Re: More Intel speculative execution vulnerabilities

#44

Post by nolok »

Jonnax wrote: post #6

So Intel failed to mitigate the vulnerability when it was first reported. Then they extended the embargo from May until November. And they still didn't fix it. What's going on with Intel? Like they're going all in with lying in benchmarks against AMD and straight up forgetting what has been reported as security issues.

Zen and Zen+ may have been strong competitors that Intel was unprepared for, but at least they were still competing, notably in per core performance. Now Zen 2 is out and Intel is taking a beating in every category, from price to power usage to multi core performance to single core performance and everything in between.

Meanwhile it became clear that a decent part of Intel's per core advantage was because of massive shortcuts they took, notably security wise, and so fixing those security holes takes away the performance.

In that situation, I doubt management at Intel is eager to take out yet another one of their shortcut. Intel needs a win, but they are not at all in the state of mind necessary to achieve one...

Re: More Intel speculative execution vulnerabilities

#45

Post by alkonaut »

HelloNurse wrote: post #38
alkonaut wrote: post #27

Earlier quoted context omitted.

Surely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution? Is the answer (for home users ) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some o…

Not very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program. Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.

How is the attacker outside, assuming it's a process running on the emulator (I.e. the attacker surface here in the emulator example would be only the NES game, so he has to work with NES cpu opcodes, NES memory locations etc)?

Re: More Intel speculative execution vulnerabilities

#46

Post by jotm »

dijit wrote: post #41
scandinavian wrote: post #28

Earlier quoted context omitted.

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…

What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably…

Ha, I had the same thought, comparing this to antivaxxers.

The downsides are of course, infinitely lower (stolen password vs disability or death), but yeah the similarity is there.

We've yet to see a real world attack using any of these, however.

Re: More Intel speculative execution vulnerabilities

#47

Post by nolok »

foxes wrote: post #4

Another nail in the casket lake. Is the solution just to throw everything out and start again? Do we just abandon speculative execution?

The problem for most of these is not speculative, it's not doing proper acl during speculation. Just because the cpu is speculating doesn't mean it shouldn't check if you are allowed to access this or that, but that's what Intel did, and they only did the security check at the end before giving back the result, except at this point its too late you've already accessed it.

Other manufacturers AMD included didn't get affected by those variants.

Re: More Intel speculative execution vulnerabilities

#48

Post by scandinavian »

dijit wrote: post #41
scandinavian wrote: post #28

Earlier quoted context omitted.

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…

What are you even talking about? the introduction to this problem came with a proof-of-concept _IN JAVASCRIPT_.[0] Session keys, private keys, passwords and all other kinds of access tokens that your system is using, it's the next worst thing from remote code execution. Your browser runs so much untrusted code that it's really unreasonable, and yes, we should definitely be pushing back hard on this. But it's probably…

From the comment in your link:

> It's missing the entire actual implementation of the Spectre attack, which requires analysis of read times to see if you're hitting the processor cache or not.

"analysis of read times" is what the browsers "fixed" to mitigate the attacks (and site isolation later). Again, there has been no working attacks on updated browsers.

Please feel free to link an example of one though, I will gladly admit I'm wrong. You just seem to frankly have no idea how the exploits actually work though (did you actually read the code in the reddit post?), so I suspect that this conversation will be a waste of time.

Re: More Intel speculative execution vulnerabilities

#49

Post by wtallis »

segfaultbuserr wrote: post #31
wtallis wrote: post #13

Earlier quoted context omitted.

> This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

I'm well aware of the impressive achievements of the old HP. But I'm also aware that that era was already clearly over in the year 2000, and they were already a very different company from what their older reputation suggested. In 2000, there was no "collapse coming" for HP from anything like mismanagement or complacency; they weathered industry-wide troubles as well as any other company and didn't experience any personal catastrophes. If the next 20 years for Intel end up like the last 20 years for HP, then long-term investors will be quite satisfied.

Re: More Intel speculative execution vulnerabilities

#50

Post by cookiecaper »

segfaultbuserr wrote: post #31
wtallis wrote: post #13

Earlier quoted context omitted.

> This place is what Hewlett-Packard was probably like in 2000 (with the printer monopoly), the collapse is coming, but without starting over there is no way to fix it. Interestingly, that printer monopoly seems to be doing fine today, given how I have to go to hp.com to get drivers for my Samsung printer.

Hewlett-Packard was an electronic engineering, semiconductor, and computing company from the beginning (the first product they sold was an audio distortion analyzer, it used a creative circuit to achieve high performance at minimum cost), they used to do serious and innovative R&D. There were the glorious days when Hewlett-Packard makes state-of-art test equipment and semiconductor devices, developed in-house enterpr…

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 in their technical specialties. At some point, the MBAs take over, attempt to put it on autopilot, and it's all downhill from there.

Post reply on HN