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

171–180 of 192 posts

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

#171

Post by angry_octet »

nullc wrote: post #143
subway wrote: post #84

Earlier quoted context omitted.

IPMI is fantastic, so long that the understanding is in place that access to your IPMI vlan may as well be considered root access to the node. BMCs tend to be pretty miserable when it comes to security. It's generally a good idea to have ACLs in place to ensure BMCs can only communicate with a secured management node, and importantly that BMCs cannot communicate with each other .

Back when boards kept the IPMI on a separate interface it was easy to isolate them, including shutting down all port to port traffic on a switch. Now, on many motherboards the BMC stuff will aggressively talk in-band even if you think you've disabled that.

And even if all the dedicated IPMI ports are on a separate switch, if you have root on one box, you can attack another via the IPMI network. You have to put ACLs on the switch to prevent traffic except to the admin node.

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

#172

Post by reirob »

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

Thanks for posting it. Strangely both the T450s and 25 (anniversary edition) are not listed at all?!

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

#173

Post by criddell »

rphlx wrote: post #114
throwaway613834 wrote: post #108

Earlier quoted context omitted.

>> 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)?

The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the…

Are you sure? As I understood it, the first two things that the ME runs on boot do much of that configuration. I can never remember the name of the first, but the second is the bring-up (or BUP) module.

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

#174

Post by mtgx »

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…

Except some researchers have disabled it? Including Google.

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

#175

Post by MisterAV »

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…

Ehm, on my Haswell motherboard there is a HW jumper called "ME disable" and it works quite fine... Also people have found different methods to set a bit that effectively shutdown the ME: These were put there by Intel even if they aren't official or supported for the general public.

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

#177

Post by arca_vorago »

badminton1 wrote: post #66

The ME should not even exist. Best way to secure it is to remove it. Problem solved. They will of course not let go because it's a backdoor. It's an overprivileged computer within your computer.

The NSA has an NSL and threats of jail to anyone at Intel who pushes back against this. Inslaw and Promis was always leading to this, and that's why they killed Danny Casalero.

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

#178

Post by rst »

mysterypie wrote: post #87

When I run the detection tool, I get: Based on the analysis performed by this tool: Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer). Does that mean that the Intel ME is disabled, so I don't have to worry about it? I certainly don't want to install anything that might enable the Intel ME if it's already disabled! What a quandary. Thi…

That's what you get if the tool can't identify the ME version. (I get "not vulnerable" if I run the script with sudo -- ME version too old for these vulns, though likely has other, undisclosed vulns -- but without sudo, I get "may be vulnerable", since it can't talk to the kernel driver.)

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

#179

Post by jordigh »

timonovici wrote: post #152
jordigh wrote: post #123

Earlier quoted context omitted.

> The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying…

The source code won't give you shit. Even if you have it all, right here, right now: 1. you cannot disable it completely - there's an image of Intel ME, burned into the chipset, which checks for the presence of the ME + AMT in the SPI flash, and it checks for signature. (There's an exception to this, with skylake and above) 2. you cannot run a modified or reverse engineered version of it, unless you have Intel's priv…

Well, source code under GPLv3 would prevent this too. The source code is one building block, but it's not the only one. It does seem like a necessary building block to begin with, though. Otherwise, how could you make the hardware do what you want it to do if you don't even have access to modify what it's currently doing?

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

#180

Post by 0culus »

mrsteveman1 wrote: post #131
0culus wrote: post #104

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?

I suspect they'll be patching this one, but I don't know if they have updated the ME firmware in the past. However, Intel's own platform tools (MEInfo and MEManuf running in a UEFI shell) can't even communicate with the ME on my 2015 Macbook Pro, so I would be quite interested to know what exactly they have done differently with regard to configuring the platform. People have been archiving every version of the ME fi…

Very interesting! Thanks for the link. I'm curious if Apple has done something to disable it either themselves or via a special deal with Intel. It's also interestingly timed with the announcement of the new iMac apparently having an A10 coprocessor.[0]

[0]: https://www.macrumors.com/2017/11/19/imac-pro-a10-chip-hey-s...

Post reply on HN