Intel Responds to Security Research Findings • Hacker News Board

Re: Intel Responds to Security Research Findings

#111

Post by Nition » Wed, Jan 03, 2018, 9:33 PM UTC

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…

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://news.ycombinator.com/item?id=12793033

Re: Intel Responds to Security Research Findings

#112

Post by f4rker » Wed, Jan 03, 2018, 9:33 PM UTC

ejcx wrote: 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…

>"quick to throw [..] under the bus, without ever having been on the other side of the table

this is so much of the internet now. people who have zero experience in a field talk with great confidence and passionate words about what must be done

many times i have posted on my areas of expertise and am almost universally crapped on by novices

people think because they have wikipedia, sometimes read the ny times, and listen to that 1 really good podcast that they are experts in all sorts of things.

Re: Intel Responds to Security Research Findings

#113

Post by jsteemann » Wed, Jan 03, 2018, 9:35 PM UTC

vhold wrote: post #82

myth_buster wrote: post #37

Intel believes these exploits do not have the potential to corrupt, modify or delete data. Followed by... Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. This press release is a minefield. There are whole paragraphs devoted to say nothing.

Somebody please correct me if I'm wrong, but I believe they're basically saying "These exploits do have the potential to read data."

Yep, seems to me they put much work into the statement "the exploits do not have the potential to corrupt, modify or delete data.".

Which leaves open if (that?) reading of data is possible. And as this is not explicitly denied, we have to fear this is exactly what is possible.

Re: Intel Responds to Security Research Findings

#114

Post by rbanffy » Wed, Jan 03, 2018, 9:35 PM UTC

aceofspad4s wrote: post #25

bkeroack wrote: post #14

Earlier quoted context omitted.

That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.

They would have to screw up really bad for people to go to AMD. I think that may never happen.

People who need to get absolutely the most bang for the buck have no ties to any given supplier. Cray deployed one of the first Opteron-based supercomputers.

Intel got lots of datacenter business simply by having a better (as in "better suited to our demands") product than anyone else in the segment. AMD has a short time window to make some large sales. They have until Intel ships a microcode fix or a new line of processors.

Re: Intel Responds to Security Research Findings

#115

Post by slizard » Wed, Jan 03, 2018, 9:36 PM UTC

thehardsphere wrote: post #92

betterunix2 wrote: post #49

Earlier quoted context omitted.

We know that AMD is not affected: https://lkml.org/lkml/2017/12/27/2

We know that "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against." E.g. that AMD does not need the patch that Intel does. That is not the same as saying AMD is not affected at all. We do not know what the actual bug that prompted this activity is. Nobody has revealed that information. It is possible that the bug affects AMD also but does not require th…

That's correct and it is a fair way to see it. However, Intel dragging two of its main competitors name into the limelight is a rather uncool move.

Re: Intel Responds to Security Research Findings

#116

Post by rbanffy » Wed, Jan 03, 2018, 9:36 PM UTC

bkeroack wrote: post #14

rbanffy wrote: post #11

Wouldn't it be wonderful if we could buy the latest Xeons at a 30% discount? ;-)

That's why they're the dominant player. Because even when a horrible defect is exposed people still desire the product over the competition.

> even when a horrible defect is exposed

Are you sure AMD parts have no horrible defects of their own?

Re: Intel Responds to Security Research Findings

#117

Post by frik » Wed, Jan 03, 2018, 9:37 PM UTC

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…

Intel should now recall the affected CPUs and ship new fixed CPUs without Intel "ME" for Management Engine, another well known open flaw.

In the end, hardware and software devs in the 1970s were right. Operating systems like MULTICS and computers like PDP-11 got it right. MULTICS supported 16 rings and has many advanced features that almost everyone forgot and never implemented in newer OS - shame on all of us!

Intel CPUs barely support more than 2.5 rings (if you count the VT that just blowed up). Also operating systems need to now focus on supporting more rings too. Just 2 rings aka kernel and usermode (and VT supervisor as third) is NOT enough in 2018.

Re: Intel Responds to Security Research Findings

#118

Post by Dylan16807 » Wed, Jan 03, 2018, 9:39 PM UTC

thezilch wrote: post #46

mannykannot wrote: post #26

Interesting 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…

> There are a lot of times you trust everything running on your box and don't need to take the perf hit.

This is true.

> Intel (and possibly other archs/families) found a perf win that ends up having security implications. A perf nonetheless. If you're willing to bet on your userspace not reading kernel pages, does Intel have a feature for you!

This I'm more skeptical of. My best guess is that this is something that saves nanoseconds, but the mitigation is massively more expensive than simply not having the feature.

Re: Intel Responds to Security Research Findings

#119

Post by Nition » Wed, Jan 03, 2018, 9:40 PM UTC

AshleysBrain wrote: post #21

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

Re: Intel Responds to Security Research Findings

#120

Post by AshleysBrain » Wed, Jan 03, 2018, 9:40 PM UTC

nebulous1 wrote: post #84

AshleysBrain wrote: post #21

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

> Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"... Has to be pointed out that they were correct. Public outrage forced them to change their tune, but their original summary was still on point. That said, it of course could majorly impact a select few.

Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.