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

Intel Responds to Security Research Findings

newsroom.intel.com

Post reply on HN
Print view View original

191–200 of 245 posts

Re: Intel Responds to Security Research Findings

#191

Post by IMcD23 »

rpns wrote: post #10

It comes across as fairly defensive. Presumably the statement was hastily put together, but it's not really the tone you want to strike when you have a lot of worried customers wondering what is going on. > Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers. A rather bizarre s…

According to Google's Project Zero post [1], Intel has known about this since 2017-06-01.

1. https://googleprojectzero.blogspot.com/2018/01/reading-privi...

Re: Intel Responds to Security Research Findings

#193

Post by losteric »

haberman wrote: post #177
redcalx wrote: post #164

Earlier quoted context omitted.

It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.

Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about t…

I think that analogy paints a pretty clear picture, this is a flaw because it's undesirable behavior in unexpected circumstances. A bug is unexpected behavior in expected use-cases.

Re: Intel Responds to Security Research Findings

#194

Post by arghwhat »

haberman wrote: post #149
bjornedstrom wrote: post #73

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…

I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for example). A new class of exploit was recently discovered, and these CPUs are vulnerable to this new exploit. But there was no bug in how these CPUs were implemented, and the only design flaw is that they failed to withstand a new class of exploit that was not k…

I do not think the processor was designed to improperly unwind from speculative execution, such that the state after failed speculation is not identical to the state prior to speculation.

But yeah, this an old discussion, and a deep rabbit hole. There's many layers to consider bugs at. Implementation can differ from developer intention, developer intention can differ from group agreement, group agreement can differ from design document, design document can differ from product development intention, and product development intention can differ from communicated functionality.

I'm betting this would be implementation differing from developer intention, although I would consider (almost) all of the above to be bugs.

Re: Intel Responds to Security Research Findings

#196

Post by _0w8t »

bjornedstrom wrote: post #73

This is probably one of the poorest and most defensive PR pieces I've read from a company in a long time, and it does not really make me sympathetic to them at all. > Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operat…

Formally it is a bug in the spec, so indeed Intel products performs as designed. What is deceptive in the first part that the text does not tell that the design and specs were also done by Intel.

Re: Intel Responds to Security Research Findings

#197

Post by mehrdadn »

nebulous1 wrote: post #185
mehrdadn wrote: post #159

Earlier quoted context omitted.

> Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division. It actually doesn't even sound comparable to me, let alone worse. A wrong division is an operation producing incorrect results contrary to the specifications, plain and simple. What we have is a CPU producing correct results, and simply refusing to provide a guarantee about caching or timing. In particular it ma…

Wait, what? If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. Now the speculation about the underlying problem could be way off, but if not it would be hard to see how Intel would argue that it isn't a bug.

> If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue.

I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". You're muddying the waters here as to what you mean by "the issue". People often (even rightly) have "issues" with things that go beyond, you know, actual issues with those things. They do this because they extrapolate and their assumptions turn out to be incorrect, and they get annoyed (again, in this case, rightly so). And that's what I'm saying here: yes, this is a genuine issue for people, but no, far as I'm aware, all Intel has guaranteed is a certain behavior for each instruction, and as far as I'm aware, no specification has been violated. Hence this is a very different situation from one where they are violating their own specs and producing incorrect output.

If you can point to one guarantee in their specs that they violate (this may not be hard -- I have barely read their specs, given that they are thousands of pages), then I agree, this is potentially like the FDIV bug, and I would more than love to be aware of it. Until then, I see the two as quite different.

Re: Intel Responds to Security Research Findings

#198

Post by tomxor »

IncRnd wrote: post #190
PuffinBlue wrote: post #165

Earlier quoted context omitted.

That's really the key. "No problem here, move along, move along - you won't be able to modify/corrupt/delete that password, you can only read it in plain text. Nothing to see. Move on." IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour.

> IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour. Intel wasn't being deceptive. That is exactly what they said, "software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data." This is in the very first sentence of their response.

They also stated it does not have the potential to cause deletion, modification or corruption which directly contradicts the "malicious purposes" statement.

Re: Intel Responds to Security Research Findings

#199

Post by mrmondo »

Oh god, it's got a logo: https://meltdownattack.com

"Which systems are affected by Meltdown?

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors."

Re: Intel Responds to Security Research Findings

#200

Post by IncRnd »

tomxor wrote: post #198
IncRnd wrote: post #190

Earlier quoted context omitted.

> IIUC - you can transpose 'password' with seemingly anything stored in memory managed by the kernel, so Intel using this sort of deceptive language is poor behaviour. Intel wasn't being deceptive. That is exactly what they said, "software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data." This is in the very first sentence of their response.

They also stated it does not have the potential to cause deletion, modification or corruption which directly contradicts the "malicious purposes" statement.

> They also stated it does not have the potential to cause deletion, modification or corruption which directly contradicts the "malicious purposes" statement.

You are mixing two different notions.

In security CIA = Confidentiality, Integrity, Availability.

Intel said that Confidentiality is broken by a security analysis applied maliciously (i.e. exploit), but Integrity is not. The general belief is that Availability is affected, due to a slowdown that depends on the workload.

Post reply on HN