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

171–180 of 262 posts

Re: More Intel speculative execution vulnerabilities

#171

Post by rblatz »

tylerhou wrote: post #159
SketchySeaBeast wrote: post #141

Earlier quoted context omitted.

But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?

No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files. I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code f…

> assuming you aren’t running other peoples’ VMs

But that’s exactly what cloud does.

Re: More Intel speculative execution vulnerabilities

#172

Post by jefftk »

oefrha wrote: post #146
jefftk wrote: post #92

Earlier quoted context omitted.

If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau... (Not a lawyer)

Security researchers aren’t hedge funds, most aren’t swimming in cash, and can’t borrow millions on a whim. Also, pouring your life savings into a bet like this is probably dumb.

A security researcher could partner with an investment fund, however. I agree this is too risky to be a good idea for most individual researchers to use directly.

Re: More Intel speculative execution vulnerabilities

#173

Post by abjKT26nO8 »

segfaultbuserr wrote: post #167
hghhbvv wrote: post #162

Earlier quoted context omitted.

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible. Not an EE so I’m just dumping my thoughts.

One problem of FPGAs is that the absolute dependence on proprietary tools from the vendor, the hardware industry is much more closed in comparison. By using those tools, you have to agree the terms and conditions such as the following (this one is from Xilinx), > By using this software, you agree not to: [...] display the object code of the Software on any computer screen. From a security perspective, it doesn't insp…

> By using this software, you agree not to: [...] display the object code of the Software on any computer screen.

I.e. ... I can print it? Good.

Re: More Intel speculative execution vulnerabilities

#174

Post by monocasa »

dragontamer wrote: post #163
hghhbvv wrote: post #162

Earlier quoted context omitted.

I wish FPGAs were fast enough because I don’t see how else this problem can be solved. Easy to issue a patch that fixes logic implemented in FOGA. Impossible to fix hardware rooted issues unless they work around it at a huge performance cost, if at all possible. Not an EE so I’m just dumping my thoughts.

FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive ( https://www.digikey.com/product-deta…

DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.

Re: More Intel speculative execution vulnerabilities

#175

Post by the_duke »

tylerhou wrote: post #159
SketchySeaBeast wrote: post #141

Earlier quoted context omitted.

But isn't that not where the worry is? Isn't it cloud computing and server spaces where the real damage can be done here?

No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files. I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code f…

> assuming you aren’t running other peoples’ VMs

That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts.

AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.

Re: More Intel speculative execution vulnerabilities

#176

Post by AnIdiotOnTheNet »

brewdad wrote: post #145
AnIdiotOnTheNet wrote: post #140

Earlier quoted context omitted.

> Do not fucking turn off these mitigations on desktop computers, they are too complex and run untrusted code all the time. No, fuck you. It is my computer and I have determined the threat to be extremely unlikely and the consequences of successful exploit minimal in my case, while the performance hit of mitigation is guaranteed. Stop trying to tell other people how to use their computer.

I just read your username. Well played.

It's not a joke. Only an asshole tells other people they should be doing things a certain way with absolutely no understanding of their use cases, needs, or constraints.

And I really do run my desktops with mitigations disabled. Sky hasn't fallen, computer performs better. If you're the kind of security-uber-alles idiot who thinks this is crazy, then you're using OpenBSD for your desktop right?

Re: More Intel speculative execution vulnerabilities

#177

Post by makomk »

jefftk wrote: post #92
segfaultbuserr wrote: post #84

Earlier quoted context omitted.

> a good capitalist would try to sell the discovery to the highest bidder. Not all security researchers are doing it for the money, 0day markets always exist. Malicious people who wish to use the vulnerability for profit wouldn't disclose the vulnerability to begin with. So it's not a new problem. > this case, it would probably be Intel, to "catch and kill" widespread knowledge of the exploit. Another high bidder wou…

If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Here's an example of Gotham City Research trying this approach and failing: https://www.thedrum.com/news/2017/09/21/criteo-counters-frau... (Not a lawyer)

Yeah. Someone actually tried this with AMD last year, but the security vulnerability they found was a lot less important than their breathless press release claimed and the markets basically shrugged. There was some funny business there too, with them paying third-party security researchers to confirm the bugs based on a more technical report the rest of us didn't get to see and the actual publicly-announced description they were used to lend credibility to being kept from them.

Re: More Intel speculative execution vulnerabilities

#178

Post by saurik »

scandinavian wrote: post #164
dijit wrote: post #150

Earlier quoted context omitted.

“Threat model is so strict” is weird to say when any ad network can access any and all memory on your desktop potentially. That’s a very wide attack scope.

You have misunderstood how the browser attacks work. They are limited to the memory assigned to the browser process. If site-isolation and the other browser mitigations were somehow bypassed, an ad-network would potentially be able to read some data from other loaded tabs. You can't use the speculative execution vulnerabilities to just read all system memory using a javascript exploit. Like the exploit that is the to…

The website covers a handful of things, and the RIDL exploits don't require special instructions.

> We leak a string from another process using Javascript and WebAssembly in the SpiderMonkey engine.

Re: More Intel speculative execution vulnerabilities

#179

Post by dragontamer »

monocasa wrote: post #174
dragontamer wrote: post #163

Earlier quoted context omitted.

FPGAs are significantly slower and significantly more expensive than dedicated hardware. The FPGAs used for data-center usage don't even use LUTs primarily anymore, because fully configurable LUTs are too slow and too expensive to manufacture at scale. Instead, data-center sized FPGAs use "DSP Slices" primarily (yeah, LUTS exist but its mostly DSP Slices). They're very expensive ( https://www.digikey.com/product-deta…

DSP slices aren't being made at the exclusion of LUTs on modern FPGAs. There's nothing about LUTs that are harder to make at scale than DSP slices. LUTs are just a little bank of SRAM, and SRAM is generally the most mature cells on a process node.

> DSP slices aren't being made at the exclusion of LUTs on modern FPGAs.

Of course they are. Every square-micrometer of the die is going to be either a LUT, DSP, or RAM on that chip. Xilinx makes a decision for how many of each is most useful to its customers.

> There's nothing about LUTs that are harder to make at scale than DSP slices.

Scaling "typical" designs on LUTs is worse than scalaing "typical" designs on a DSP Slice.

Synthesize a 32-bit wallace-tree multiplier for instance, and you'll use thousands of LUTs (maybe 2000ish). However, reserve a DSP-slice for a 32-bit multiply routine, and you'll only use ONE slice.

However, those multipliers on the DSP-slice could be "wasted" if you didn't need that many multipliers. Maybe your arithmetic is primarily addition and subtraction. In any case, when most people talk about "Reconfigurable FPGAs", they're talking about the LUTs which can be the building block of any logic. They aren't talking about DSP-slices, which are effectively prebuilt ALUs connected in a mesh.

Re: More Intel speculative execution vulnerabilities

#180

Post by tylerhou »

the_duke wrote: post #175
tylerhou wrote: post #159

Earlier quoted context omitted.

No, these vulnerabilities potentially let userspace code escalate privileges, which could lead to ransomware or credential exfiltration. Stealing bank account passwords clearly does damage, and various governments have paid ransoms on the order of $100,000 to recover encrypted files. I’d argue that side-channel attacks are less of a problem in the server space because servers generally don’t download untrusted code f…

> assuming you aren’t running other peoples’ VMs That's the problem right there: the vast majority of workloads in the cloud runs on shared hosts. AWS/GC dedicated host pricing is not actually that crazy of a markup (around 50% last time I investigated), but that's still very noticeable at scale, and billing granularity is by the hour.

I agree public cloud needs mitigations to be secure. But a significant number of workloads (~50%?) run on-prem or in private clouds. Those generally host "more trusted" code.
Post reply on HN