Live data from Hacker News

An in-depth security review of the Intel Management Engine

security-center.intel.com

51–60 of 192 posts

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

#51

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 paranoid. Besides, it was fun when I sounded crazy. Now it's alarming.

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

#53
post #36

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 :(

[deleted]

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

#54
post #43
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…

blackhat =/= defcon

[deleted]

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

#55
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 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 users for remote administration as well.

But it needs to be secure, and it needs to exist without secrecy. If this portion were free for the user to configure, or if they allowed complete disabling via motherboard jumper, or simply open sourced it, that would be a better step.

However, the NSA's activities have destroyed all trust in these sorts of features coming from an American company, so even if it were completely open sourced, there's no guarantee that there isn't other hardcoded ROM also executing in tandem with the open source components.

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

#56

I don't see any remote exploits here (other than "attacker with remote admin access..."). Is that correct? Presumably an attacker with remote admin access is already all powerful? Or is the concern that they can backdoor the hardware in an undetectable way, remotely?

A vulnerability where someone can remote control your machine is bad. A vulnerability where someone can remote control your machine even after you swap out all local storage and install a new OS is another thing entirely.

True but I'd still like the nature of access required to exercise these vulnerabilities clearly defined. e.g. if I have a box that I've maintained strict physical control over, and not allowed admin access to an attacker, does that mean said box can't have been subverted via these vulnerabilities?

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

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

> these are the kind of vulnerabilities that the NSA would salivate over

No need to salivate over something that you paid for and that you already used for 8 years.

Post-Snowden if you believe the NSA has already broken into most things and has very often paid to facilitate this (like loss-making Skype US server routing, or inefficiently using valuable silicon space for IME), you are no longer a conspiracy theory lunatic - you are just a mere sane person applying Occam's razor.

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

#58
Anyone able to explain why Intel’s severity rating for this is “important” and not “critical”; meaning of the terms per Intel’s own words:

“Critical: A vulnerability, which if exploited, would allow remote execution of malicious code without user action.”

“Important: A vulnerability, which if exploited, would directly impact the confidentiality, integrity or availability of user’s data or processing resources.“

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

#59
post #50

Does "attacker with local access to the system" mean "physical access to the system"?? Initially I thought it meant "attacker able to run an unprivileged process on the system" but then I see other wording that seems to imply that case, so does "local access" mean physical access? (e.g. connect a USB drive, boot the box off their own media?)

The examples I've heard about are plugging a usb drive in and that's the ballgame. The big one, that I have not heard of, would be accessing the ME and privilege elevation over network.

Network is a problem.

As I understand it, the ME subsystem is an overseer, and is running even if your main PC is powered off. It has control over the network, unobservable from the downstream CPU/OS. It could therefore receive commands/input from the network and update itself while "off", or transmit data outbound. So unless the system is unplugged from the wall, the ME subsystem could be doing God-knows-what.

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

#60
post #32
post #18

Earlier quoted context omitted.

Yep. "Let's put a chip in it" IoT nightmare now applies recursively to chips. Everything is insecure by design. I am really looking forward for either ARM to displace x64 or even better RISC-V. With ARM you have many more vendors so more chance for options, and RISC-V is the ultimate in openness.

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

At least you might be able to get a chip without a backdoor in hardware. Binary blobs are still a little easier to audit and can in theory be replaced.
Post reply on HN