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

Intel platforms from 2008 onwards have a remotely exploitable security hole

semiaccurate.com

Post reply on HN
Print view View original

61–70 of 190 posts

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#61

Post by DrPizza »

tomc1985 wrote: post #55
jnwatson wrote: post #52

Earlier quoted context omitted.

The functionality ME attempts to provide is lights out a.k.a. out-of-band management (like IPMI) to the desktop. If, for example, an admin needed to add a dual-boot-to-Ubuntu option to every PC on a floor, he could, through ME, remotely reboot (force power reset if necessary) or power on every machine, have the machines boot to a (remote) OS install disk, run the install, and reboot. ME allows one to do almost anythi…

Fine, but putting it on all hardware? How many corporate IT environments buy off-the-shelf motherboards and CPUs from the same channels as consumers? OEMs get an entirely different set of parts and enterprise sales works in completely different channels. If there is such a clean separation between corporate and consumer markets then why is this hardware on everything , and why does it need to pull power on the machin…

It isn't on all hardware. Intel has two ME firmwares, a small one for consumer systems, and a big one for corporate/enterprise systems. The small one does not (or at least, should not; is not supposed to) include the remote management features.

In other words, the separation that you describe exists.

Systems with the full firmware sport things such as the vPro branding, and only certain combinations of CPU and chipset support it.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#62

Post by tormeh »

freehunter wrote: post #58
finnn wrote: post #34

Earlier quoted context omitted.

I'm worried that it's true and it's not catastrophic for Intel. Aka show to the world that you can get away with BS like this.

The fact that people can stay behind platforms, companies, and technologies that are proven to be so inherently insecure that they can never be trusted just boggles my mind. Adobe Flash has a new zero-day every week, but we were saddled with it for years past when it should have been retired because some people didn't want HTML5 to have feature-parity with Flash. Java has a new zero-day every week but we're stuck wit…

>Java has a new zero-day every week but we're stuck with it

Well, Java applets did die. What more do you want? The Java sandbox is only used by extremely legacy software at this point, so it doesn't matter if it has holes in it. Actually, the more holes the better, so we can get rid of the last holdouts.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#63

Post by tomku »

krylon wrote: post #60

As a sysadmin at a Windows shop, I don't know what to make of this. Has Intel commented on this, yet? Any OEM? Joanna Rutkowska, who is a renowned security researcher, warned of something like this happening sooner or later[1], so I don't think I can afford to just ignore this. But without something more specific to act on, there is nothing I can do, except wait firmware updates to be released by various vendors. If…

Believe it in proportion to the supporting evidence presented. At the moment, that's nothing except an appeal to the widespread belief that an Intel ME security flaw is inevitable.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#64

Post by tomku »

Natanael_L wrote: post #56
tomku wrote: post #9

Is there a better source for this than SemiAccurate? The article doesn't really have much beyond self-aggrandizement and "we can't tell you any details, but you're screwed". For something that could be anything from "Charlie Demerjian heard a rumor about a ME patch and wanted some pageviews" to the actual security apocalypse, I'd like credible sources.

There's eventually going to be one when it is officially published by Intel, but that seems to be months away right now.

No, that's not how sources work. You don't get to use your assumption that the article is accurate to assert that it will eventually be proven accurate by other sources. That's circular reasoning.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#65

Post by eberkund »

I've always wondering why nobody seems to notice the fact that this site is literally called "Semi Accurate". I mean sure, everyone makes mistake and even the most credible news sources are not entirely accurate all the time. But what am I to think when your organization is literally named after being only half truthful?

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#66

Post by tyingq »

ajdlinux wrote: post #20
resoluteteeth wrote: post #16

Earlier quoted context omitted.

The article implies that they have been privately trying to get Intel to fix it, so there is no reason it would have been mentioned publicly anywhere. Now a patch is coming out but Intel is still trying to keep it quiet, so he's trying to warn people disable AMT and be ready to apply patches ASAP. Presumably he didn't even want to disclose the existence of the vulnerability publicly until there was some sort of fix,…

It does seem suspicious to me that this hugely critical flaw deep in the firmware stack has been discovered by the writing staff of a tech news website rather than an infosec research team...

The article sort of reads like he has thought (not known) there was an issue for a long time.

Then, he saw that Intel released a patch related to the management engine, and took that as confirmation? Maybe he has access to the release notes via a source at an OEM?

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#67

Post by dantiberian »

Sephr wrote: post #48

> For obvious reasons we couldn’t publish what we found It's not obvious to me why anyone not under an NSL or NDA would sit on this vulnerability for 5 years and wait until it's actively being exploited in the wild before public disclosure. It's extremely negligent to global security for SemiAccurate to not immediately publicly disclose the vulnerability 5 years ago after Intel refused to fix it. Of course this is ig…

This was my thought too as I read it. If they didn't feel they could handle the disclosure, Google Project Zero could have been a good recipient to report to Intel.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#68

Post by elorant »

the_common_man wrote: post #59
elorant wrote: post #47

I've disabled ME on my PC because at some point LMS (Local Management Service) started consuming too much resources for no apparent reason.

How do you disable it? In the BIOS? Is it enabled by default?

I'm running Windows and I just disabled the service. There are a couple of them, one is Local Management Service and the other is User Notification Service.

Re: Intel platforms from 2008 onwards have a remotely exploitable security hole

#69

Post by tomc1985 »

DrPizza wrote: post #61
tomc1985 wrote: post #55

Earlier quoted context omitted.

Fine, but putting it on all hardware? How many corporate IT environments buy off-the-shelf motherboards and CPUs from the same channels as consumers? OEMs get an entirely different set of parts and enterprise sales works in completely different channels. If there is such a clean separation between corporate and consumer markets then why is this hardware on everything , and why does it need to pull power on the machin…

It isn't on all hardware. Intel has two ME firmwares, a small one for consumer systems, and a big one for corporate/enterprise systems. The small one does not (or at least, should not; is not supposed to) include the remote management features. In other words, the separation that you describe exists. Systems with the full firmware sport things such as the vPro branding, and only certain combinations of CPU and chipse…

AFAIK the consumer version still kills the system if it's disabled?
Post reply on HN