“Intel Core 2 bugs will assuredly be exploitable from userland code” (2007) • Hacker News Board

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#81

Post by baldfat » Fri, Jan 05, 2018, 2:15 PM UTC

dannyw wrote: post #38

wasx wrote: post #22

Earlier quoted context omitted.

>They can a handle a bit of criticism from a bunch of nerds on HN. What a reductive and shortsighted evaluation of the situation. Can they handle the loss of faith from big companies? Can they handle the loss of faith from the entire tech community? Seems to me that AMD et al have now got the perfect opportunity to erode intels market share and build up a large market base amongst cloud providers etc (not to mention…

AMD’s x86/x86-64 Cross licensing agreement terminates if they ever have more than X (I think 30% or 50%) of the desktop and server market share, so I don’t think so. The agreement purposefully gimps AMD as a minority player.

Intel's biggest threat is not AMD but ARM.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#82

Post by Waterluvian » Fri, Jan 05, 2018, 2:15 PM UTC

jokoon wrote: post #78

I know I will sound like a conspiracy theorist, but can those bugs be intentional? I mean if you are a security agency, would it be possible to push for the introduction of such bugs?

I think it's not unreasonable to think about the possibility of that. My understanding is that these bugs could have been exploited for a very very long time without being noticed?

I also wonder if one or more security agencies find a lot of their efficacy in just a small handful of exploits. And if those were to be patched, they'd find themselves severely hamstrung. So seen as a threat to national security, they have a strong need to ensure the availability of exploits.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#83

Post by analognoise » Fri, Jan 05, 2018, 2:21 PM UTC

newman8r wrote: post #25

linohh wrote: post #2

Has HN begun to collect suggestions to intel how to handle the situation and what to change regarding community interaction to reduce the impact of such flaws? Instead of bashing our heads out, maybe it's time to offer them a hand when they're down on the ground.

If it's possible to get an eventual legal judgement against them, perhaps instead of paying x-billion dollars in fines, maybe they should be forced to make their future work open source.

1) They aren't going to have to pay a fine 2) This would just screw the shareholders, making the stock worth less 3) Open source doesn't have the people, skills, or finances to utilize Intel's internal design data - the only beneficiary from this would be other chip manufacturers and nation-states. I'm not sure who this would benefit?

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#84

Post by pier25 » Fri, Jan 05, 2018, 2:21 PM UTC

jokoon wrote: post #78

I know I will sound like a conspiracy theorist, but can those bugs be intentional? I mean if you are a security agency, would it be possible to push for the introduction of such bugs?

Possible, but I think it's more probable that security agencies took advantage of those bugs with the help from Intel than intentionally putting those there in the first place.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#85

Post by jerf » Fri, Jan 05, 2018, 2:28 PM UTC

jokoon wrote: post #78

I know I will sound like a conspiracy theorist, but can those bugs be intentional? I mean if you are a security agency, would it be possible to push for the introduction of such bugs?

Occam's Razor suggests to me that intelligence agencies have not had to push for processor bugs, on the grounds that A: we can adequately explain the initial existence of these bugs by normal engineering, marketing, and management considerations such as almost everyone here has experienced personally and B: the field of the bugs that come from my first point is so ripe that the intelligence agencies are better served by examining them carefully and finding their own exploits. The primary reason for this is that the best hidden paper trail is the non-existent paper trail; by finding bugs independently and holding all knowledge within the agency, there is zero risk of it ever being revealed that they deliberately inserted bugs into the CPU, which would be a PR disaster for all concerned (and to a non-trivial extent, an act of war).

Given that we know that intelligence agencies have asked for backdoors before, in both hardware and encryption standards, do not interpret my post here as a claim that they would never ever even think of asking for plausibly-deniable CPU bugs to be inserted into hardware. I am just saying that Occam's Razor says we should prefer the perfectly plausible scenario I gave above where they do not have direct involvement in these bugs, not because of their pristine ethics, but because given the circumstances on the ground, actively intervening is not their best choice from their point of view using their valuation function, when they can attain all their goals without active intervention.

(I'm willing to believe in things that might be labelled "conspiracy theories"; history is rife with proof that they have existed in the past, such as the aforementioned cases where we know backdoors have been inserted into crypto standards, as well as other things such as the way in which the Soviet Union was created which essentially involved what was initially a small conspiracy, and I see no reason to believe they have ceased in the modern times. But I want to see how the conspiracy theory passes Occam's Razor; many of the conspiracy-minded, in my opinion, underestimate the randomness and everything-is-always-correlated-a-bit-ness of the real world.)

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#86

Post by alex_duf » Fri, Jan 05, 2018, 2:34 PM UTC

protomikron wrote: post #72

alex_duf wrote: post #71

Earlier quoted context omitted.

That would be great. I know nothing about low level programming, and I'm wondering if webassembly couldn't be a good place to start designing CPU instruction sets? Can someone more competent on the matter tell me if this idea is crazy?

> Can someone more competent on the matter tell me if this idea is crazy? Yes, it's crazy. :) But seriously, the ISA (instruction set architecture) is not the problem, but the optimizations (deep pipelines and speculative execution, etc.) are.

thanks!

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#87

Post by newman8r » Fri, Jan 05, 2018, 2:34 PM UTC

analognoise wrote: post #83

newman8r wrote: post #25

Earlier quoted context omitted.

If it's possible to get an eventual legal judgement against them, perhaps instead of paying x-billion dollars in fines, maybe they should be forced to make their future work open source.

1) They aren't going to have to pay a fine 2) This would just screw the shareholders, making the stock worth less 3) Open source doesn't have the people, skills, or finances to utilize Intel's internal design data - the only beneficiary from this would be other chip manufacturers and nation-states. I'm not sure who this would benefit?

I was thinking the benefit would be the ability to audit it, but yeah, not going to happen.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#88

Post by anon1385 » Fri, Jan 05, 2018, 2:34 PM UTC

siwatanejo wrote: post #57

cthalupa wrote: post #53

Earlier quoted context omitted.

Except that these bugs were all open on open source operating systems, as well... Do you think Linux wasn't affected by Spectre and Meltdown? That the BSDs aren't? That Xen isn't? Your comment is disingenuous and dangerous.

You're (and most likely all downvoters) completely missing the point. I never said that opensource software is not affected, I said "not being affected as a user". Because opensource software, being peer-reviewed, will never try to exploit a CPU bug. Opensource software is, by default, non-malicious.

So what you are saying is that if you never install closed source software, you will never (intentionally) install malware because you define all malware as closed source. This is a meaningless tautology. The advice you are giving is both objectively wrong and actively dangerous.

Firstly not all security issues involve installing 'malware'. Take heartbleed; a major security vulnerability in open source software. To be hit by that you didn't need to install any non-open source software. You could have had the most pure and open stack of software and hardware ever created and it would have made no difference because the flaw was an information leak that didn't involve installing software or even unintended remote execution of code. That bug was due to the existing already installed open source code copying past the end of a buffer. Similar information leaking bugs could feasibly exist due to CPU bugs or compiler bugs or undefined behaviour in the code etc (i.e. all sorts of ways that don't involve installing malware and aren't even obvious from reading the code).

Secondly, even exploits that do involve "running malware" are very often not because the user intentionally installed malware. They happen because the user did something like download and decode an image file which took advantage of a vulnerability in their (open source!) image decoding library to execute code on their machine. Again in this scenario it doesn't matter that the user would only ever intentionally install open source software, because the malware was executed unintentionally when they performed an activity they didn't expect to lead to code execution (viewing an image).

E: These CPU issues are fundamentally timing attacks that leak information. I don't need to execute code on your computer at all to run a timing attack against you that leaks valuable information - I can do it by sending packets of pure data and don't need to be able to execute arbitrary code on your machine at all. Side channels like timing attacks don't necessarily require any kind of code execution on the target machine (although obviously having a high precision local timer makes it easier). This isn't just theoretical, it has been demonstrated in reality. For example see this paper[1] which demonstrates doing timing attacks against a browser to reveal the users browser history without the need to execute javascript at all. It's all done by sending CSS, which isn't code.

[1] https://www.nds.rub.de/media/nds/veroeffentlichungen/2014/07...

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#89

Post by theptip » Fri, Jan 05, 2018, 2:37 PM UTC

jokoon wrote: post #78

I know I will sound like a conspiracy theorist, but can those bugs be intentional? I mean if you are a security agency, would it be possible to push for the introduction of such bugs?

Does the NSA use Intel chips? If so, it would seem unlikely that they made their own compute infrastructure insecure.

Their mission isn't to make everything less secure, it's to make the other team's stuff less secure (where "other team" includes the citizens of the US apparently).

Furthermore, given the number of bugs in just about every piece of software (including kernels), I don't think these bugs are even an anomaly that needs an explanation. Bugs exist in every complex system, and CPUs are very complex these days.

That said, to address your direct question of "would it be possible", I'm fairly sure it would; we have hints from Linus that Three Letter Agencies have asked him for backdoors, so I'm sure large hardware companies have open channels with the NSA et. al. as well.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#90

Post by mannykannot » Fri, Jan 05, 2018, 3:05 PM UTC

mrep wrote: post #54

forapurpose wrote: post #28

Earlier quoted context omitted.

> Industry experts have been expressing concerns for this for ten years. AFAICT, de Raadt was concerned about Intel in general, but not the recent exploits in particular. We can find endless criticisms of every major company from the last 10 years (including on HN!); picking this one mailing list posting is bit arbitrary in the context of these exploits, even if de Raadt makes some good general points.

I work with a bunch of hardware engineers who used to work at intel and the really knowledgeable ex-intel guy I know said speculative execution has always been known to be risky but actually exploiting it was presumed to be very difficult/impossible. Looking back, I should have asked him how intel evaluates security risks considering how much of modern day computing uses it (which makes it an extremely valuable black…

In practice, if you cannot demonstrate an exploit, your concerns will be heavily discounted, and this is a case in point. Even if you do show an exploit, attempts will often be made to dismiss it as infeasible in practice (this is for security issues in general, not specifically Intel.)