>Intel believes its products are the most secure in the world
After the Intel ME mess? I'm not so sure.
Intel Responds to Security Research Findings
181–190 of 245 posts
Re: Intel Responds to Security Research Findings
#182This 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…
> This is deceptive. In the first sentence it combines two statements: 1) bug/flaw in Intel products and 2) that it is unique to Intel. In the rest of the paragraph it then claims that the previous statements are incorrect, but only addressing the second point.
This is excellent analysis. I guess my follow up question is has there been anything to suggest that AMD/ARM are or are not vulnerable in a similar manner?
I read this as Intel trying to imply that other vendors weren't probed and/or may not have this specific design vulnerability but can still be vulnerable...which I consider a vapid statement designed to distract the reader.
True, when a 0-day is found and disclosed it doesn't mean that there aren't other 0-days that haven't been found yet...but that has no relation to the significance of the newly disclosed vulnerability.
I judge this statement even more harshly because the flaw is so serious it's under embargo until OS vendors can try to protect users. Additionally, AMD seems to have said their processors are not vulnerable (https://lkml.org/lkml/2017/12/27/2)...
Edit: Some more information from Google Project Zero:
https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
So maybe AMD and ARM are vulnerable?
Edit 2: So it seems there are two slightly different attacks along this vector: Spectre and Meltdown. From the Google article(s) it seems Spectre affects Intel, AMD, ARM while Meltdown only affects Meltdown. This would appear to contradict the AMD statement regarding their processors not being affected.
I am not hardware guy and information is still coming out...but I am judging this Intel press release slightly less harshly (although it still reads pretty vapid).
Re: Intel Responds to Security Research Findings
#183Earlier quoted context omitted.
> since they are addressing it soon. They make it seem like everyone should be working in the same boat to address this I can assure you that indeed "everyone is working in the same boat to address this", and has been doing so for months, across multiple OS and processor vendors. It's already public that Microsoft and Apple have also implemented page table isolation, and certainly Intel didn't name-drop AMD and ARM c…
> and certainly Intel didn't name-drop AMD and ARM carelessly in the press release. I'm sure it wasn't careless, but they are (from all accounts I have read) blatantly lying. Intel isn't known for above board practices. They will do what it takes to win - period. Name dropping their competitors (to me), honestly shows me how dire of a situation this is. If it wasn't, they wouldn't feel the need to defend themselves a…
According to project zero report, a lot more than intel CPU's are affected by this issue. See relavant HN post here
"These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."
Re: Intel Responds to Security Research Findings
#184Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)
[deleted]
Re: Intel Responds to Security Research Findings
#185Earlier quoted context omitted.
Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
> 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.
Re: Intel Responds to Security Research Findings
#186Earlier 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 guess overall I think this is fair to call a "flaw" but not a "bug."
Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.
Re: Intel Responds to Security Research Findings
#187This 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…
> This is deceptive. It immediately mentions AMD to give the impression that AMD also suffer from the problem. It looks like (some?) AMD processors might be affected as well: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them."[1] [1] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
From what I can gather, one of the 3 issues found is Intel-only, very bad and very easy to exploit, and can be patched with a large performance hit.
Another is harder to exploit, and has no known workaround (likely requiring new silicon to fix), and affects basically all micro-architectures in use today, including AMD's x86 silicon.
The third, I know nothing of.
Re: Intel Responds to Security Research Findings
#188Interesting use of language: 'Recent reports that these exploits... are unique to Intel products are incorrect... Intel is committed to product and customer security and is working closely with many other technology companies, including AMD...' Someone new to the issue might think AMD also has this problem. Similarly (replacing the first elision in the above quote): 'Recent reports that these exploits are caused by a…
Not defending Intel here, but devils advocate... You will find many clients asking how to disable, for example, the Linux patch. Linux is releasing with a flag to disable it, so there is some merit. Why would you want that? There are a lot of times you trust everything running on your box and don't need to take the perf hit. Intel (and possibly other archs/families) found a perf win that ends up having security impli…
> Intel found a perf win that ends up having security implications.
Every Intel CPU has a lower perf than you will find on current benchmarks, but yes, there's a perf enhancement that will make the chip as fast as expected, but has security implications.
Re: Intel Responds to Security Research Findings
#189Project Zero has published a detailed writeup on this. It's worth noting (in the context of Intel's response) that the P0 post confirms that AMD and ARM CPUs are also affected:
"Variants of this issue are known to affect many modern processors, including certain processors by Intel, AMD and ARM. For a few Intel and AMD CPU models, we have exploits that work against real software. We reported this issue to Intel, AMD and ARM on 2017-06-01"
https://googleprojectzero.blogspot.com/2018/01/reading-privi...
Edit: Discussion https://news.ycombinator.com/item?id=16065845
Re: Intel Responds to Security Research Findings
#190Earlier quoted context omitted.
Uh... they don’t say the exploits don’t allow for READING of data... That’s the most concerning thing then
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.