Intel ME: The Way of Static Analysis | Hacker News Reader

Intel ME: The Way of Static Analysis

blog.ptsecurity.com

85 pointsqznc25 comments

Revenge of the Tanenbaum: Finally, he found a way to control Linux ;-)

just kidding

That was a really good one :)

I found some accompanying slides: https://www.troopers.de/downloads/troopers17/TR17_ME11_Stati...

That said, please note that this is partially outdated information (even to the extent of warranting a mod edit even though it's so recent) - the parts that mention how some compressed modules are unreadable are now irrelevant.

The URL for this article is /2017/04/ (April).

More recently (July, three months later), this same group has somehow (??) managed to derive the Huffman compression tables for the previously-inaccessible modules: https://github.com/ptresearch/unME11

I haven't read anything that explicitly states this (on HN; I don't read anywhere else), but I get the impression this is the holy grail, or at least one of the major pieces of the puzzle.

I found this random comment about actually using unME11: https://news.ycombinator.com/item?id=15447841

This recent HN article suggests that it's also possible to get arbitrary remote code execution, but no details are (yet) forthcoming. https://news.ycombinator.com/item?id=15298833

This post seems outdated considering these more recent HN posts:

Disabling Intel ME 11 via undocumented mode (ptsecurity.com) https://news.ycombinator.com/item?id=15116719

How to hack a turned-off computer, or running unsigned code in Intel ME (blackhat.com) https://news.ycombinator.com/item?id=15298833

Personally I am extremely curious about the upcoming blackhat presentation. If it is really true this might be very big.

Being able to run unsigned code in ME might allow (depending on how the exploit works) for either a replacement of the ME firmware entirely or just doing a disable that exceeds even the HAP bit (and the rest of magic that me_cleaner does to remove different sections of the firmware). But we'll have to wait for the slides, I'm hoping there's something really useful there for the coreboot community.

Well, it might also allow for the ultimate rootkit hack of x86 platforms...

Well, it is technically a little outdated. The article OP posted is from April of this year, and the one you linked to was posted in August.

In addition to those two discussions (Aug 2017, 218 comments) & (Sep 2017, 239 comments), the following came up this week:

Disabling the Intel Management Engine | https://news.ycombinator.com/item?id=15444607 (Oct 2017, 219 comments)

If nothing else, the BlackHat talk has stirred up interest in the Intel ME which had remained in relative obscurity for quite some time.

I don't know what kind of speculations one could have about that.

To be honest the more transistors components have, the more it is possible to have underlying software that can manage things or even be used as a backdoor.

Am I right to be concerned about this, if only in principle? I don't like having a mysterious embedded chip that can access the network when my computer's off.

Exactly. What is Intel's supposed reason for having such a feature?

It's in the name, it's for management of enterprise deployments of machines that have Intel CPUs[1]. It's a fairly important thing for most enterprises (sort of like IPMI but it's not just for servers), as it allows you to do a variety of things to all computers that you manage.

Now, whether that feature should be part of every consumer CPU is a valid question and concern -- one that nobody has the answer to. Likely the reason for this is that modern versions of ME also do hardware initialisation[2], so it would make sense for Intel to not require manufacturers to rewrite all of that code for their consumer machines. There have been exploits in Intel ME in the past, which are quite concerning (and the fact it's proprietary is obviously a concern, given how many privileges it has over the system).

You can neuter Intel ME on old machines (pre-BootGuard) using me_cleaner[3], but it requires attaching a flash programmer to your motherboard. If you have coreboot you can do it from userspace.

[1]: https://en.wikipedia.org/wiki/Intel_Active_Management_Techno... [2]: https://www.coreboot.org/Intel_Management_Engine [3]: https://github.com/corna/me_cleaner

The Unix server vendors had these features long before Intel did. Having a common out-of-band management interface is hugely valuable for fleet management.

It's not valuable at all for individual retail consumers; in the long run, SGX probably does for the entire Intel customer based, including retail, pretty much everything that the ME might have done for retail users.

The real question is why there's no way to disable it. Certainly, if it was only for out-of-band management then why can't a retail consumer disable? Saying that it's because it does "hardware initialisation" is a weak response, Intel could've designed it in a way that doesn't do that such as with the very first models of CPUs with ME.

Was it universally easy to disable the lights-out managers on Unix server platforms 10-15 years ago, or did vendors sometimes omit that feature because only a tiny subset of their customers cared about that?

I'm not saying you shouldn't be able to disable it.

I would think it's more pertinent to ask "is there an economic reason to allow a retail consumer to disable it". Most people don't know (or care) what Intel ME is, and some enterprises that buy machines with Intel CPUs want the management features. Companies aren't implicitly evil, they just don't have altruistic motives (generally). Which means that likely they didn't see it as having a good ROI. This is not what you or I want to be the case, but even if that were solved -- Intel CPUs have a whole variety of other issues that extend beyond ME.

But all of that is missing the point that there is a way to disable it[1], with the HAP or AltMeDisable bits[2]. It's believed they were added for the US government to be able to disable Intel ME (after hardware initialisation). It's not easy (you have to reflash the firmware) because most vendor firmware doesn't allow "internal" flashing from userspace, but it is doable if you buy a $5 flash programmer and a Raspberry PI.

[1]: https://github.com/corna/me_cleaner [2]: https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bi...

You're contradicting yourself, maintaining that they didn't allow disabling the ME because "nobody cared", and on the other hand that they specifically crafted a way to disable the ME for the US government. If they did for the US government, but hided it for everyone else, then the explanation can't be economical.

I'm not contradicting myself. The US Government isn't a normal consumer, and they have enough manpower to manually flash their machines (they might even get custom firmware from vendors).

Intel hiding CPU features is nothing new. Especially a feature that requires you to attach a flash programmer to your motherboard in order to use it, because you need to modify the descriptor table.

If you're asking why they didn't make it easier to "disable" Intel ME (it's still used for hardware initialisation), then we go back to economics. And they'd have to co-ordinate with people that write mainboard firmware in order to make sure this feature is available for all machines that have Intel CPUs.

[Just to be clear, I'm also critical of Intel. I just don't understand the view that Intel's decisions are anything other than profit-driven. That's how all companies work.]

I thought that the ME was some weird off-brand JVM? Maybe that was a prior revision?

The JVM runs as process on the OS. Older MEs used ThreadX on an ARC CPU. Current ME is the Quark x86 core (~486 class, in-order execution) running MINIX. Probably still running their JVM for applets (the off-CPU McAfee compliance manager is probably built that way).

We put an x86 in your x86 so you can... never mind. :)

Does the quark have its own ME? :)

Mini ME :)

Minix would be the OS that the JVM runs on top of.

That's pretty cool tbh.

Finally some geek cred for the ME.

Reply on news.ycombinator.com