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

131–140 of 262 posts

Re: More Intel speculative execution vulnerabilities

#131

Post by mandevil »

segfaultbuserr wrote: post #103
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)

> If you discover a flaw in a product, bet against the stock, and publish the flaw, that's not insider trading. Thanks for the information, never thought about that. On the other hand, would purchasing information about a flaw and using the information to bet the stock constitutes insider trading?

It would be insider trading if the person you purchased from had a duty to the company to keep the secret (they worked for the company and learned of the vulnerability in the normal course of their job, say). If they are an independent researcher and you are an independent researcher, trade away. Then it is just like using satellites to find out that a shopping mall's parking lot is empty on a big shopping day- trade all you want.

If they signed a NDA to cash in on the bug bounty and then sold it to you, I think they are vulnerable to breach of contract, but I don't think you are legally vulnerable, however this is not legal advice, I am not a lawyer, and do you want to go through the expense of finding out?

Re: More Intel speculative execution vulnerabilities

#132

Post by wyldfire »

> On July 3, 2019, we finally learned that, to our surprise, the Intel PSIRT team had missed the PoCs from our Sep 29 submission, despite having awarded a bounty for it, explaining why Intel had failed to address - or even publicly acknowledge - many RIDL-class vulnerabilities on May 14, 2019.

What does this usage of the word 'missed' mean in this context? That they lost it / failed to deliver the PoC to the relevant team? Or that they released a "fix" knowing that it didn't defeat the PoC?

Re: More Intel speculative execution vulnerabilities

#133

Post by whatshisface »

jjoonathan wrote: post #121
S_A_P wrote: post #86

Earlier quoted context omitted.

Somewhat tangential point: having a single technological leader is a significant risk. Thankfully AMD is hitting its stride again and seems to be at least somewhat immune or less susceptible to this class of attack. Apples arm processors are approaching x64 performance in some cases. Imagine if Intel had squashed the competition only to find their architecture is a security risk. As it is now, it really sucks to know…

If the vulnerability pipeline is a few years deep and AMD wasn't considered a worthwhile target a few years ago, we might not want to interpret a lack of AMD vulnerabilities as evidence that they are immune.

AMD was always a worthy target because they sold a lot of cost-effective mid and low range CPUs to Dell and friends. They have been absent from the peak performance market for a while but that's a small fraction of computers. After all, AMD didn't go out of business, and they had to be selling a lot of CPUs.

Re: More Intel speculative execution vulnerabilities

#134

Post by jhalstead »

IntelThrowaway wrote: post #51
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.

One of the problems with Intel culture - especially under BK was that the philosophy was "Focus on our key goals to the exclusion of everything else". It was meant to keep focus and ensure we moved quickly. The problem with that is it meant we were entirely unresponsive. It doesn't matter if something important has come up because you've already agreed what the priority is, you've already committed to what you're goi…

Dumb question: Can you clarify what ZBB'd means in this context? I've never seen it before. There's a wiki page [0] with various meanings for the abbreviation, but nothing seemed to fit. Maybe Zero-based budgeting?

[0] https://en.m.wikipedia.org/wiki/ZBB

Re: More Intel speculative execution vulnerabilities

#135

Post by rrss »

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.

> going all in with lying in benchmarks against AMD

I'm assuming this is referencing the "intentionally misleading benchmarks" piece in servethehome. It's worth reading the follow up, in which the author discovers their biggest complaint (older version doesn't have avx2 enabled by default on zen2) was not an issue because Intel manually enabled avx2.

https://www.servethehome.com/update-to-the-intel-xeon-platin...

Re: More Intel speculative execution vulnerabilities

#136

Post by yifanl »

coldtea wrote: post #99
wolf550e wrote: post #36

Earlier quoted context omitted.

No. This timeline shows incompetence, not sitting on their hands: https://mdsattacks.com/#ng-full-story

Incompetence as in "they're incompetent engineers", and if so, compared to what baseline? Or incompetence in as "they weren't capable of doing it"? The latter is very probable. The former could underestimate the difficulty of such fixes...

The two statements are identical, competence is always within a given context.

Re: More Intel speculative execution vulnerabilities

#137

Post by rrss »

wolf550e wrote: post #9
iforgotpassword wrote: post #7

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

AMD (and ARM OoO chips) are vulnerable to Spectre variant 1 (bypass in-process array bounds checking) but not to the vast majority (any?) of the other issues which are Intel-only. AMD chips don't have the feature that speculation failure is determined at instruction commit time when it is already too late, so most issues just can't happen.

AMD processors were also vulnerable to spectre v2. I don't know the status of the mitigations or whether it was fixed in zen 2.

EDIT:

I found the list I made a few months back. no guarantees, but i think it is mostly accurate.

Meltdown: Intel, IBM, some ARM

Spectre v1: Intel, ARM, IBM, AMD

Spectre v2: Intel, ARM, IBM, AMD

Spectre v3a: Intel, ARM

Spectre v4: Intel, ARM, IBM, AMD

L1TF: Intel, IBM

Meltdown-PK: Intel

Spectre-PHT: Intel, ARM, AMD

Meltdown-BND: Intel, AMD

MDS: Intel

RIDL: Intel

Re: More Intel speculative execution vulnerabilities

#138

Post by Khoth »

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)

Also not a lawyer, but check what country you're in before you try this. In countries like the UK, many more things are insider trading than in the US.

Re: More Intel speculative execution vulnerabilities

#139

Post by lsofzz »

ageofwant wrote: post #63
coldtea wrote: post #35

Earlier quoted context omitted.

> No I don't give a fuck about the 'risk' this introduces Well, let's hope you're not powned because of this and get dragged into giving some fucks, for a 5-10% of performance hit you wouldn't notice anyway...

Pray, why do you think I would expend the effort of deliberately increasing my 'exposure' if I did not notice the effects of these mitigation on my workloads ? And they are not particularly unique. Do you understand my risk and load requirements better than I do ? Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ? But thanks for y…

> Have you entertained the possibility that the decision to de-mitigate was the result of considered risk and resource management modeling ?

What do you mean by `resource management modeling` in this context? Do you mean `capacity planning` or `system scaling planning` or something else altogether?

Re: More Intel speculative execution vulnerabilities

#140

Post by AnIdiotOnTheNet »

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…

> 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.

Post reply on HN