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

An in-depth security review of the Intel Management Engine

security-center.intel.com

Post reply on HN
Print view View original

101–110 of 192 posts

Re: An in-depth security review of the Intel Management Engine

#101

Post by wolfgke »

disconnected wrote: post #48
thg wrote: post #17

Earlier quoted context omitted.

Well, maybe AMD does at least some security reviewing on their own? /s ARM could be a affordable alternative to x86 if that works for you.

> ARM could be a affordable alternative to x86 if that works for you. Even the open source friendly Raspberry Pi relies on proprietary blobs and proprietary firmware, with vast parts of the documentation only being available to system integrators (meaning: not you) under an NDA. Theirs is a Broadcom chip, but my understanding is that the scenario is pretty much the same for other ARM vendors. If the chip is anything…

> Even the open source friendly Raspberry Pi

Broadcom (producer of the chips used on the RPi) and open source friendly? A sense an oxymoron.

Re: An in-depth security review of the Intel Management Engine

#102

Post by wolfgke »

mastax wrote: post #79
my123 wrote: post #32

Earlier quoted context omitted.

Good luck getting a modern ARM SoC which doesn't depend on binary blobs.

i.MX6 is modern-ish and is bootable without blobs.

> i.MX6 is modern-ish and is bootable without blobs.

i.MX8 will soon be released in quantity to the public and it is claimed by people who experimented with testing samples of it that it is similarly open as the i.MX6 in this sense.

Re: An in-depth security review of the Intel Management Engine

#103

Post by lorenzhs »

_x5tx wrote: post #36
jlgaddis wrote: post #26

I prefer the wording in Lenovo's security advisory [0]: > "Potential Impact: An attacker could load and execute arbitrary code outside the visibility of the user, operating system, and hypervisor/virtualization platform; resulting in exfiltration of secrets, subtle manipulation of system operation, or denial of service." [0]: https://support.lenovo.com/us/en/product_security/len-17297

It is nice to know lenovo already has the updates, but sadly I'm gonna have to install windows for that :(

You can create a Windows PE image which can be booted from a USB thumb drive, see my comment further down this thread: https://news.ycombinator.com/item?id=15744152

Re: An in-depth security review of the Intel Management Engine

#104

Post by 0culus »

How does this affect Apple products? I've looked around for discussion of Intel ME with regards to Apple and the silence out there is deafening. [edit] I guess I also want to know is, does Apple provide Intel firmware patches bundled with their own software update?

Re: An in-depth security review of the Intel Management Engine

#105

Post by ChuckMcM »

aeleos wrote: post #8

Wow all 6th, 7th and 8th gen are all vulnerable along with a bunch of Xeon processors. Even the laptop I am typing this on is vulnerable, this is going to be messy. Plus all the fun vulnerabilities like arbitrary code execution, unauthorized access to privileged content. These must be related to the blackhat talk coming up in December about hacking a turned-off computer and running unsigned code on ME [0]. Yep and th…

I was going to contribute something similar, I recall early dismissals suggesting that the 'low end' machines didn't have this capability. I recall Mike Guimarin's comment of "If transistors are free (and they are) why not cut down the internal SKUs and put this on all processors" which apparently Intel did.

Of course as it becomes clear you can (and should) disable it, if you do that on a corporate laptop you might find that your IT team is both mad and proud of you at the same time. Quite the quandry.

Re: An in-depth security review of the Intel Management Engine

#106

Post by javajosh »

derefr wrote: post #96
white-flame wrote: post #55

Earlier quoted context omitted.

> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal us…

> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonom…

It's sad to me that manually setting an IRQ is so horrible a prospect that it's better to compromise the entire system.

Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity entirely.

Then we can worry about something else, which is secretly embedding mini-CPUs into the CPU itself.

Re: An in-depth security review of the Intel Management Engine

#107

Post by ficklepickle »

xwvvvvwx wrote: post #90

Could someone explain what Management Engine is actually used for? It’s still not really clear to me why it needs to exist at all. Serious question.

Remote administration. Installing a new OS remotely, for example. There is legit demand for that. Imagine manually re-imaging 1000 workstations or servers.

Re: An in-depth security review of the Intel Management Engine

#108

Post by throwaway613834 »

derefr wrote: post #96
white-flame wrote: post #55

Earlier quoted context omitted.

> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal us…

> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonom…

>> or if they allowed complete disabling via motherboard jumper

> That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.)

Then how does Intel disable it for governmental customers (high-assurance)?

Re: An in-depth security review of the Intel Management Engine

#109

Post by stefantalpalaru »

xwvvvvwx wrote: post #16

Unreal. Kept scrolling and the vulnerabilities kept coming. Most annoying thing is that there isn’t even a real alternative. If I understand it right then AMD chips have pretty much the same thing?

> Most annoying thing is that there isn’t even a real alternative. If I understand it right then AMD chips have pretty much the same thing?

Yes, but it was implemented only after Piledriver (family 15h). I have an FX-8320E overclocked at 4.4 GHz on all cores, all the time (turbo core disabled) and I'm happy with it.

Re: An in-depth security review of the Intel Management Engine

#110

Post by emmelaich »

jackhack wrote: post #51
joe_the_user wrote: post #4

So, will Intel be patching both the vulnerabilities and the kludges people have found to remove ME? Thus making some customers safer while maintaining systemic risk for everyone? "Asking for a friend"

>>Thus making some customers safer Customer. Or customers (plural)?? I ask, because I assume this amount of complexity wasn't created because it was cheap, or end-users were crying out for it. There may be other customers -- those with three-letter agency names, who would wish for code to run on the computer you possess (note, I did not say "own", so long as someone else has control). It's getting too easy to be this…

It's called the Manageability Engine. It's there to manage. They didn't do it to please three letter agencies.

Now that doesn't mean that the TLAs haven't found and used a vulnerability but that's like everything in a computer.

Post reply on HN