
Intel ME: The Way of Static Analysis - qznc
http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html
======
JepZ
Revenge of the Tanenbaum: Finally, he found a way to control Linux ;-)

 _just kidding_

~~~
ricogallo
That was a really good one :)

------
exikyut
I found some accompanying slides:
[https://www.troopers.de/downloads/troopers17/TR17_ME11_Stati...](https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf)

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](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](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](https://news.ycombinator.com/item?id=15298833)

------
moppl
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](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](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.

~~~
cyphar
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.

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

------
jokoon
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.

------
theprotocol
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.

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

~~~
tptacek
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.

~~~
jerheinze
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.

~~~
cyphar
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](https://github.com/corna/me_cleaner)
[2]: [https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-
bi...](https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit)

~~~
jerheinze
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.

~~~
cyphar
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.]

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

~~~
pgeorgi
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).

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

~~~
dman
Does the quark have its own ME? :)

~~~
type0
Mini ME :)

------
grabcocque
That's pretty cool tbh.

Finally some geek cred for the ME.

