
Intel Management Engine cleaner - BuuQu9hu
https://github.com/corna/me_cleaner/
======
leonroy
I remember the furore when Intel introduced a unique CPU identifier in the
Pentium 3. Now they have a microprocessor and OS running as a computer
subsystem on every Intel server and laptop which is able to do pretty much
what it likes with your system and people don't bat an eyelid.

Don't get me wrong, I love some of the benefits like remote control of my
servers, fan speed control, monitoring of temps and voltages etc. but I do
think we've given up a LOT of security for the sake of convenience. It
wouldn't take much for a well crafted worm or heck a simple script to disrupt
a whole network of ME/AMT enabled clients and servers.

~~~
hannob
> but I do think we've given up a LOT of security for the sake of convenience.

Worse: There is no reason you couldn't have both. For a start: A simple "off"
switch for Intel ME would please a lot of people.

~~~
ComodoHacker
>A simple "off" switch for Intel ME would please a lot of people.

But not a corporate security team, of course. It's not that simple.

~~~
Quequau
Sure it is, it's just that "off" needs to be done by Intel and sold under a
different SKU.

~~~
wang_li
It doesn't even need to be that. Expose it on a header on the motherboard so
end users can add/remove a jumper. Same as should be in place for the write
enable pin on the system's firmware EEPROM. The fact that the end user has no
way to prevent firmware updates on most motherboards is a fucking travesty.

Businesses can simply tell their employees to leave it enabled or find another
job.

~~~
shitloadofbooks
But when it gets stolen, the thief just switches the jumper.

------
AdmiralAsshat
A story:

One of my coworkers told me he previously worked on the motherboard team for
Intel and was regaling the office with stories about testing the motherboards
against the latest games. Apparently many of the Intel engineers personally
tested overclocking the processors to see how much they could take before they
fried.

At some point I asked him if he knew anything about the Management Engine. He
said that they were starting to become a thing right around the time he was
leaving, so he didn't know too much about them. I said, "Well, there's a bunch
of paranoid people that are uneasy about it because, to my understanding, it's
a blackbox second processor and we really have no idea what it's doing."

Without prompt, he replied, "Oh, you mean like the FBI using it to listen in?
Yeah, that happened. It happened on AT&T's when I went over there as well."*

That's my story. I apologize if it looks like I'm spreading FUD here, since
I'm not going to give up my name or my coworker's to verify the story, but I
sincerely doubt that Intel would acknowledge such a capability anyway, so,
take it as you will. Libreboot, the Management Engine cleaner, and other such
projects _need_ to exist. My coworker's comment convinced me of that.

* I'm not sure what he's referring to here. Maybe someone else can shed some light. Does AT&T make processors?

~~~
Someone1234
I'm skeptical that the FBI have the technical capabilities to turn the IME
into a trojan horse (in the biblical sense). More likely NSA-levels of
sophistication. Plus there's also the issue of doing the actual implants
(either via postal intercepts, physical access, or breaking into networks)
which are illegal for the FBI to do but semi-legal for the NSA to do against
foreign targets.

~~~
dromen
Can't the FBI request services from the NSA?

And there have been versions of the Intel ME in the wild with known remote
exploits AFAIK.

~~~
dv_dt
Isn't this a two edged thing in legal courts - if there is a widely available
backdoor to hack Intel systems, how can any digital evidence be taken without
some measure of doubt?

~~~
AnthonyMouse
That is the whole "parallel construction" debacle. Once they have the
evidence, they come up with a cover story for how they could have legally
obtained it.

------
nailer
Background, ie why you might want to clean Intel ME:
[https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf](https://recon.cx/2014/slides/Recon%202014%20Skochinsky.pdf)

~~~
kawsper
Also, [https://libreboot.org/faq/#intelme](https://libreboot.org/faq/#intelme)

~~~
SEJeff
And an obligatory link to CoreBoot, which I believe has a bit more history
than Libreboot:

[https://www.coreboot.org/Intel_Management_Engine](https://www.coreboot.org/Intel_Management_Engine)

~~~
mordocai
Libreboot is just a more strict about freedom coreboot from what I understand.
As in it is literally a fork/derivative of coreboot.

~~~
SEJeff
Ah got it. With the recent GNU drama of libreboot I wonder how viable it
really is as an ecosystem.

~~~
yuhong
Personally I think the FSF ideology taken too far is pretty ridiculous anyway.

~~~
nfoz
Yet here we are, discussing the secret OS that runs on its own chip and can't
be disabled by the end-user.

The world is a pretty ridiculous place, even with the best efforts of those
ridiculous FSF zealots. I don't always agree with them and their methods and
communication skills aren't perfect, and it's a shame to see
coreboot/libreboot get fragmented etc... but imagine how backwards the world
would be without some people taking things 'a bit too far sometimes'.

------
TorKlingberg
The ME causes problems for embedded system makers too. If you are making
physical devices with Intel CPUs you probably want to replace the Intel MAC
addresses with your own. Then you have to fight with the ME to keep it from
trying to talk to the internet by itself, using the Intel MAC. If it does,
that will freak out some corporate routers. They see two MAC devices on one
port and assumes someone has plugged in an unauthorized ethernet switch, and
disable the port.

~~~
DashRattlesnake
Hmm, that behavior might enable a neat non-firmware mitigation: replace the
Intel MAC address with your own and block all packets originating from the
Intel one.

------
Create
Doctorow's Law: "Anytime someone puts a lock on something you own, against
your wishes, and doesn't give you the key, they're not doing it for your
benefit."

------
d33
> It should work both with Coreboot and with the factory BIOS.

So, basically any computer?

Also, how safe is it?

EDIT:

> Bricking is very likely to happen! Just in case you didn't hear me the first
> time

~~~
d33
It looks like its wiki sheds some light on the details:

[https://github.com/corna/me_cleaner/wiki](https://github.com/corna/me_cleaner/wiki)

------
SimplyUnknown
One thing I asked before but didn't get a definitive answer on: IIRC the IME
images are cryptographically signed, right? If so, how can they modify the
images without breaking the signature? Or can they resign it?

~~~
mid-kid
As far as I know, only the code is signed, not the partition table. This means
that you can freely modify the partition table and completely remove some
modules.

~~~
mid-kid
Please check the wiki for more detailed information:
[https://github.com/corna/me_cleaner/wiki/How-does-it-
work%3F...](https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F#why-
does-it-work-arent-the-partitions-signed-how-can-you-modify-them)

------
dbcurtis
One thing that concerns me is that it says it removes parts of the ME
responsible for "silicon work-arounds". In other words, microcode patches.
These are important for patching processor errata.

It would be better if there was a way to allow retaining/updating microcode
patches for errata, while eliminating all the other nonsense.

~~~
oneplane
It is my understanding that those microcode patches can be applied by the OS
as well at runtime.

~~~
nowaynohow
Sort of. Removing the firmware-provided microcode update would likely kill
Intel SGX support, though. And if UEFI is set for secure boot _and_ its
implementation happens to uses SGX or TXT for that, it probably will brick the
box until one restores its system FLASH to a valid state.

You can further update the processor microcode later, from UEFI or from the
operating system. But the all-important initial processor microcode[1] update
has to be done from a trusted path [for Intel SGX to be available].

And no, it is not UEFI early boot updating the microcode as it used to work in
the past: when doing a secure Intel SGX boot path, the microcode looks up the
FIT table in system FLASH, to get the address of a microcode update table in
system flash. If found, the microcode then proceeds to self-update from FLASH.

This whole auto-load-microcode-from-FIT thing seems to have started with
Skylake. Since Intel SGX is almost entirely implemented in microcode, it makes
a lot of sense.

ON INTEL SKYLAKE AND LATER, you can notice whether the current microcode
update came from FIT or not by reading its revision number. If it is odd, it
came from the FIT. If it is even, it came from regular UEFI or O.S. updates.

[https://review.coreboot.org/cgit/coreboot.git/commit/?id=504...](https://review.coreboot.org/cgit/coreboot.git/commit/?id=5042aad4ded1651638ae9b60e34114b65e4f211e)

As for recent Intel systems without Intel SGX (or with it disabled), you still
likely need a firmware-provided initial microcode update or it will be
hopelessly buggy. Chances are it won't be stable enough to actually boot the
target O.S.

[1] Intel has been shipping its processors with shamelessly incomplete/buggy
factory microcode for a while now. You pretty much _have_ to install a
microcode update, or what you will get might not even qualify as a X86-64
compatible processor. The factory microcode doesn't need to know how to do
paging or hardware-assisted virtualization correctly at all, for example, or
even implement SIMD and floating point math instructions. All it has to do is
to be able to run enough of BIOS/UEFI to get the initial microcode update.

------
newman314
I wonder if this would work on a Mac. Looked around briefly but did not see
anything indicating support.

------
digler999
This is admittedly unfounded speculation, but if the ME were compromised, one
of the most valuable things an attacker would want would be AES keys. So _IF_
this binary blob is up to no good, we should expect one of its tasks to jot
down AES keys (remember, intel has had specialized AES instructions for a
while now) and hide them somewhere for later retrieval.

Perhaps it would behoove people to run a "keyscrubber" daemon that constantly
generates random numbers and AES-encrypts a few kb of data and sends it to
/dev/null. _IF_ the ME is jotting down keys, and _IF_ there is only a finite
amount of space for it to store them, such a daemon might be able to flush out
_real_ keys and overwrite them with junk to hamper any retrieval efforts.

Again, two big hypotheticals, but, if it were stealing keys, the buffer would
have to be pretty small, otherwise people could eventually detect it changing
sizes or hashes in NVM. I wouldn't expect such a thing in standard redable NVM
anyway, it's probably on a die somewhere and only a few kb.

~~~
owenmarshall
> This is admittedly unfounded speculation, but if the ME were compromised,
> one of the most valuable things an attacker would want would be AES keys. So
> _IF_ this binary blob is up to no good, we should expect one of its tasks to
> jot down AES keys (remember, intel has had specialized AES instructions for
> a while now) and hide them somewhere for later retrieval.

If you want to get into the speculation rabbit hole, it's far more fun to
assume that instead of calculating something_truly_random(), RDRAND actually
returns `AES-CTR(something_truly_random(), NSAKEY, counter)` as random output
- which then becomes P & Q for your RSA keys. This'd be a far easier attack to
mount, and wouldn't require any exfiltration of keys; just being able to see
any current RNG state would expose all the previous states.

This might not be a problem for Linux, since RDRAND is mixed in, but for a
while RDRAND was the exclusive entropy source for TCP sequence numbers, ASLR
offsets, etc: [https://cryptome.org/2013/07/intel-bed-
nsa.htm](https://cryptome.org/2013/07/intel-bed-nsa.htm)

Who knows how Windows or OS X handles this.

~~~
digler999
>just being able to see any current RNG state would expose all the previous
states.

wow, that's insidious. I'd never even considered something like that!

