Live data from Hacker News

Intel Responds to Security Research Findings

newsroom.intel.com

171–180 of 245 posts

Re: Intel Responds to Security Research Findings

#171
post #32
post #16

Lots of people being critical of this response. I think it's pretty good, and have been on the disclosing side of this equation many times. Admits responsibility and says their current course of action (working with key stakeholders). Addresses concerns of the workaround. Has a timeframe for future updates. Has a call to action for what you should be doing next. To those of you pointing out that this is PR, you're ri…

It's also manipulative, mentioning AMD and ARM for no other reason to make people think those also have the flaw.

ARM 64 does have the flaw. The tricksy wording is probably that AMD does manufacture some ARM 64 chips, so perhaps they were involved in that fix.

Which is still intentionally misleading on Intel's part.

Re: Intel Responds to Security Research Findings

#172
post #119

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase. > Recent reports that these exploits are caused by a “bug” or a “flaw” [Unprivileged] reading from kernel memory i…

That "bug" or "flaw" sentence is very carefully worded. It's like: bool bug = true; bool flaw = true; bool uniqueToIntel = false; bool reportsAreTrue = (bug || flaw) && uniqueToIntel; // reportsAreTrue == false!

Yes it's designed in such a way that in a court of law they could claim they were announcing a bug, but most or many people reading it would come to the opposite conclusion. In other words it's deceptive.

Re: Intel Responds to Security Research Findings

#173
post #111

Earlier quoted context omitted.

Yeah, I had to read the “bug” or “flaw” part twice to be sure they're not saying it isn't a bug or flaw, they're only saying it isn't unique to Intel. And then as you say, they immediately mention AMD to imply that everyone has the issue, but they also avoid actually saying that. Your excellent analysis of what they're really saying reminds me of user thaumaturgy's analysis of Adancing Our Amazing Bet[1]. [1] https:/…

Bet you a dollar some lawyer had to vet that three times over before they published it.

My suspicion is they don't get sued; rather, Werner Vogels calls Intel and tells them the massive haircut / refund they're gonna take. Or Werner buys amd procs.

Re: Intel Responds to Security Research Findings

#174
post #111

Earlier quoted context omitted.

Yeah, I had to read the “bug” or “flaw” part twice to be sure they're not saying it isn't a bug or flaw, they're only saying it isn't unique to Intel. And then as you say, they immediately mention AMD to imply that everyone has the issue, but they also avoid actually saying that. Your excellent analysis of what they're really saying reminds me of user thaumaturgy's analysis of Adancing Our Amazing Bet[1]. [1] https:/…

Bet you a dollar some lawyer had to vet that three times over before they published it.

With the obvious class action suit that's coming, I don't know what else better their counsel has to do on a Monday night.

Re: Intel Responds to Security Research Findings

#175

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Isn't the quote above which is from the Intel press release a blatant lie? All the articles I have seen say this only affects Intel processors. Not AMD processors nor, ARM, MIPS, SPARC or PowerPC chips. Did I miss something or is Intel lying in it's press release.

AMD manufactures some ARM 64 chips, which might make this "technically true" albeit intentionally misleading.

Re: Intel Responds to Security Research Findings

#177

Earlier quoted context omitted.

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…

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 that? The last one seems like the closest analogy.

Another example: would you say that MD5 is buggy/flawed?

I guess overall I think this is fair to call a "flaw" but not a "bug."

Re: Intel Responds to Security Research Findings

#178

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…

>...pointing out what the exploits cannot do (corrupt/modify/delete).

That statement is also untrue if you follow the implicit issue to it's inevitable exploitable end... Here is an equivalent statement of equal absurdity that intentionally neglects causality:

"Our door lock design contains a bug. The bug does not make stuff in your house disappear, does not manifest junkies into the vicinity, nor does it make property spontaneously combust."

Re: Intel Responds to Security Research Findings

#179
post #167

Earlier quoted context omitted.

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…

This feels pretty deceptive when the most relevant competitor, amd, is not susceptible...

[deleted]

Re: Intel Responds to Security Research Findings

#180

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 am going to go on a limb and speculate that Intel probably knows more about this problem than most. They are being quite specific that the issue affects multiple devices, and I doubt they are lying. And coincidentally several other reports (from Google, Wired and others) are indicating that this issue crosses CPU makers.

In that context, isn't you reply rather off the mark? If Intel's claim is correct, then being "defensive" seems entirely accurate given how many are foaming at the mouth at the prospect of some mortally wounded Intel.

Post reply on HN