
Neutralize ME Firmware on SandyBridge and IvyBridge Platforms - madars
http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
======
sounds
This appears to be a legitimate ME neutralization.

The ME is purportedly placed in "recovery" mode:

    
    
      According to Nicola Corna, the current ME state should have been changed from “normal” to “recovery”.
    

Since the MEI interface is disabled (not visible from a PCI bus scan), there
is no way to activate the ME at runtime, even after a full system compromise.
It would still be possible to rewrite the BIOS flash chip with a new ME image,
but the system would need to be restarted before the ME would read the
changes.

I don't speak for the FSF, but it sounds like this is as close to an FSF RYF
certification as any Intel CPU is going to get. FSF approval of a device
requires that all user-modifiable software be Free Software. Previously, no
recent Intel CPUs could be FSF certified as "RYF" because the ME chip would
shut the system down after 30 minutes. (Side note: no recent Intel CPUs can be
considered "stable" without microcode updates which also violate the FSF's RYF
guidelines.)

[1] [http://www.fsf.org/resources/hw/endorsement/respects-your-
fr...](http://www.fsf.org/resources/hw/endorsement/respects-your-freedom)

~~~
tunesmith
ME isn't the last obstacle though, is it? Looking at the purism/librem pages,
there are still various other subsystems like FSP/EC/SMC.

[https://puri.sm/posts/bios-freedom-status-
nov2014/](https://puri.sm/posts/bios-freedom-status-nov2014/)

~~~
sounds
The FSP is a package (the P in FSP). It includes in it the ME blob. The other
parts of it are things like DRAM init. It would take work to develop a fully
libre implementation for any Intel chipset, but the biggest hurdle was (and
is) the ME blob in the FSP.

The EC, SMC, and other blobs are much more the domain of the board designer,
and are much easier to make a libre implementation for.

~~~
igor_sk
>It includes in it the ME blob

No, it does not. FSP only includes x86 code to be executed on the main CPU. It
may include stuff which talks to the ME but no ME firmware itself. You can use
any UEFI extractor like UEFITool to check that.

------
twr
I succeeded at doing this to an old Asus Z68 motherboard. Steps:

    
    
      flashrom -p internal -r bios.rom
      ifdtool -x bios.rom
      python3 me_cleaner.py flashregion_2_intel_me.bin
      python2 dump_me.py flashregion_2_intel_me.bin -x
      python2 me_sigcheck.py FTPR_part.bin
      ifdtool -i ME:flashregion_2_intel_me.bin bios.rom
      exit # Skip this line if you're okay with bricking your motherboard.
      flashrom -p internal -w bios.rom.new
    

`lspci | grep -i mei` and `lsmod | grep mei` are now empty.

intelmetool:

    
    
      ME: FW Partition Table      : OK
      ME: Bringup Loader Failure  : NO
      ME: Firmware Init Complete  : NO
      ME: Manufacturing Mode      : NO
      ME: Boot Options Present    : NO
      ME: Update In Progress      : NO
      ME: Current Working State   : Initializing
      ME: Current Operation State : Bring up
      ME: Current Operation Mode  : Normal
      ME: Error Code              : Debug Failure
      ME: Progress Phase          : BUP Phase
      ME: Power Management Event  : Pseudo-global reset
      ME: Progress Phase State    : 0x3b
      ...
      ME has a broken implementation on your board with this BIOS
      ME: failed to become ready
    

It took a hard reset to re-enable integrated ethernet.

Awesome!

~~~
corna
Please report it here
[https://github.com/corna/me_cleaner/issues/3](https://github.com/corna/me_cleaner/issues/3)

Thanks

------
kevin_b_er
rootkit is defined by google search as "a set of software tools that enable an
unauthorized user to gain control of a computer system without being
detected."

* A set of software tools: Check

* Unauthorized user: Check Caveat: user is not authorized by you, but by someone else (Intel)

* Gain control of a computer system without being detected. Can access your machine while it appears to be "powered off" but plugged in. Has full access to RAM. Can draw undetected on top of screen. Can read screen. Check.

So. Does this qualify the Management Engine as a rootkit? It meets the
definition. Just because the rootkit is installed by the manufacturer doesn't
make it less of one.

~~~
yuhong
AFAIK the remote network access ("AMT") has to be specifically enabled.

~~~
nitrogen
Some of the paranoia around ME is the possibility of undocumented commands or
magic byte sequences in software or via network interface that give an
attacker invisible control of the ME without the user enabling AMT. The NIC is
probably still powered and active for WoL.

It's also conceivable that a state-level adversary could have hidden arbitrary
DMA instructions in a NIC firmware, that only activate with a signed request
embedded in a random packet. Some of the largest firmware blobs on Linux
systems are for NICs.

Most people aren't facing state-level targeted attacks, but without open
firmware, it's nearly impossible to know for sure if one is vulnerable. And,
with botnets and worms, it only takes one non-state-level attacker discovering
the backdoor for everyone to be affected.

------
snvzz
The ridiculous shit that needs to be done just to rid of some blob.

RISC-V can't take the market over fast enough.

~~~
TD-Linux
How much are you willing to pay for it?

There's the Talos Secure Workstation, which has no such ME firmware (but costs
~$4.5k) [1].

A RISC-V desktop is pretty far out. There is an Arduino style microcontroller
being made in silicon, though [2].

[1] [https://www.crowdsupply.com/raptor-computing-
systems/talos-s...](https://www.crowdsupply.com/raptor-computing-
systems/talos-secure-workstation) [2]
[https://www.crowdsupply.com/onchip/open-v](https://www.crowdsupply.com/onchip/open-v)

~~~
feld
Not really. They're talking Raspberry PI type devices based on RISC-V on the
market by late 2017.

Source: MeetBSDCon 2016, update on RISC-V by the team who designed it.

~~~
BuuQu9hu
[https://youtu.be/QTYiH1Y5UV0?t=39m20s](https://youtu.be/QTYiH1Y5UV0?t=39m20s)

------
phantom_oracle
Has Intel ever commented about this issue of removing ME?

Surely, at least 1 Intel staffer reads HN and they must have discussed this
internally.

Unless they just brush this off as negligible (a couple thousand
paranoid/"extremist" users) ?

~~~
wmf
Their discussion may have consisted of "too bad these extremists don't realize
that the ME is harmless if you don't have an Intel NIC".

~~~
devereaux
There is a device visible on the PCI bus. How hard is it to imagine that
userland programs could somehow pass requests to that device, and have the ME
do bad things to the CPU or the RAM?

How hard is it to imagine some special string in RAM could trigger the ME in a
similar way? (so many CPU instructions - I would be surprised if there wasn't
one to talk to the ME)

Exploits and vulnerability are mitigated by proper analysis and ecological
diversity.

Here we have an attack channel present of every single Intel based computer,
regardless of the CPU.

Call me an extremist if you want, but this is far from harmless.

~~~
tedunangst
If userland processes are passing unauthorized commands to PCI devices, you
have bigger problems.

~~~
ackalker
They're called proprietary video drivers, and yes, they pass unknown commands,
without user authorization (think DRM) to PCI(e) devices (video cards) all the
time.

~~~
lallysingh
If you're running highly privileged binary blob drivers, is ME really the
attack vector you should be worried about?

------
WhitneyLand
Beautiful work. Standing offer to buy dinner for any of the contributors if
they come through Dallas.

------
bsharitt
As a potential backdoor with access to a computer with compromising the OS,
how much is ME neutralized by just not using the integrated NIC and instead
using a PCI-E or USB NIC?

~~~
sounds
The ME firmware includes a Java VM so that other companies can run their
secret apps inside the ME's environment (e.g. DRM crypto plugins). That is
just one example of all the features included in the ME firmware, and none of
it is published or well documented, much less audited at the source level by
an independent third party.

The ME is very alarming, and seems to only become more alarming the closer you
look at what it is designed to do.

~~~
qb45
And any code running there can read and write your RAM as it pleases because
"ME is secure and obviously nothing bad can ever happen there so there's no
reason to protect other things _from_ the ME".

------
gwu78
Seems like the BBB is more versatile than the x220. Not to mention it has no
ME.

+1 for the use of ifdtool.

------
Puts
What happened to VIA and their x86 CPUs and mini-itx platform people used to
build media PCs on? Wouldn't that be a viable option if you really want to
avoid ME?

~~~
PeCaN
VIA is still around. They announced a new core with AVX2 support, Isaiah II,
around late 2014 but it appears their x86_64 license will run out before it
actually gets produced. The situation is really unclear. In 2010 they got a
6-year license extension thanks to the FTC, so it's possible VIA can't
actually produce x86 CPUs anymore.

VIA is 100% a viable option—they support SSE 4.1, run Windows 10, and their
integrated GPUs even run DirectX11 natively¹—except that _they compete with
Atom, not desktop or even regular laptop CPUs_. However, the current (40nm
Isaiah) “high-end” VIA microarchitecture is a out-of-order, 3-fetch 7-dispatch
wide² superscalar, fully pipelined core. So it should outperform a modern Atom
by a decent margin, with only slightly higher power consumption.

Apparently VIA is still fairly popular in China (and by virtue of being a
Taiwanese company, possibly Japan as well).

1\. See e.g. [http://www.viatech.com/en/boards/mini-
itx/epia-m920/](http://www.viatech.com/en/boards/mini-itx/epia-m920/)

2\. [http://arstechnica.com/gadgets/2008/01/via-cpu-
isaiah/2/](http://arstechnica.com/gadgets/2008/01/via-cpu-isaiah/2/)

------
spikengineer
Any research on how to disable AMD PSP.

------
tedunangst
What if I like using the integrated NIC?

~~~
kevin_b_er
The NIC permits remote access to the Intel rootkit, you probably don't want to
use the NIC.

~~~
jameskegel
Can you elaborate?

~~~
yuhong
It is supposed to be used for corporate environments using Intel AMT for
remote management.

------
yuhong
I think the most important lesson is that the arms race against laptop theft
is ridiculous.

