Neutralize ME Firmware on SandyBridge and IvyBridge Platforms | Hacker News Reader

Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

hardenedlinux.org

337 pointsmadars75 comments

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

I worked with Nicola at the script. Apparently the same firmware modification can be done up to Skylake CPUs, but it is to be checked if ME firmware modification triggers Boot Guard BIOS signature verification. We don't know yet because the only person who tried this on Skylake seems to have Boot Guard not enabled on his board. More info: https://github.com/corna/me_cleaner/issues/1

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/

FSP is a binary running on the CPU, unsigned. That can be replaced with a reimplementation (and was for Sandybridge/Ivybridge)

EC/SMC are highly board specific, some even run open source firmware that can be replaced (eg. on Chromebooks)

The issue with the ME is that its firmware is signed with an internal Intel key, combined with its property of having full access to the entire system.

Even with this hack of invalidating most of the firmware, we don't know for sure what is left running on the ME.

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.

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

> but the system would need to be restarted before the ME would read the changes.

# shutdown -r now

# echo "1" > /proc/sys/kernel/sysrq

# echo b > /proc/sysrq-trigger

# rm -rf /*

edit: there was a star but HN formatting ate it

Exactly. In modeling the threat that the ME poses to a libre system, the ideal would be to have it "gone," such that it will never activate regardless of what is in the BIOS flash.

That's not possible, but the next best thing is to have it never activate unless major changes are made to the BIOS flash, and those changes should be very visible.

Your computer suddenly reboots: very visible.

The flash partition table and/or BIOS suddenly change: very visible.

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!

Please report it here https://github.com/corna/me_cleaner/issues/3

Thanks

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.

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

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.

http://people.kth.se/~maguire/DEGREE-PROJECT-REPORTS/100402-...

PDF Page 66

This attack could be used indefinite times to compromise the Intel’s AMT remote provisioning process and subverts the security of the non configured PCs that include the AMT functionality even while it is disabled within the BIOS configuration as presented in section 3.7.6.

AMT is always active, even if you've set it to "Disabled" and can be remotely activated. Again, without your authorization.

The paper is nice, however it covers an ancient AMT version. AFAIK this won't work on recent versions (it has saner defaults).

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

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

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... [2] https://www.crowdsupply.com/onchip/open-v

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.

https://youtu.be/QTYiH1Y5UV0?t=39m20s

Note that it looks like they may not make their goal. It ends on Dec 15th, and they only have about 10% raised ($344,310 raised of $3,700,000 goal)

It's only 32bit. This is not something I'm interested in funding. If it was 64bit or the 128bit version of RISC-V it would be more alluring.

Where did you read that? The TALOS machine uses POWER8 which is 64 bit. EDIT: Ah right there are two different links above

It's a microcontroller. Think ARM Cortex-M0.

> How much are you willing to pay for it?

Wrong question. Correct question would be: "How much are you willing and able to pay for it?" (for me it much more strongly fails because of the second criterion).

If you're willing to pay more than you're able to, I think you need to reevaluate your approach to personal finance first.

Thanks, but I believe my approach to personal finance is quite right and responsible. This does not contradict the fact that there are things that I am willing to pay for, but not able to. Exactly because my approach to personal finance is responsible, I don't spend money in this situation.

I think we must understand the word "willing" differently.

It's more than just "some blob" though. ME is a system within your system, that is completely out of your control. [0]

[0] https://libreboot.org/faq/#intelme

A rootkit can be anywhere on the PCIe bus.

Just for example, you are using OpenBSD and full disk encryption and you think you are safe? What if the firmware on your NIC can be altered to scan your RAM (using DMA) and send the interesting data (big prime numbers, passwords, etc.) home? What if firmware on your keyboard can be modified (or pre-programmed in factory) to record the last x thousands of keypresses (which will include your boot disk password) on its own flash memory which can be later extracted? There are so many attack vectors.

This is one reason I do like the features of newer CPUs like amds Zen line with memory encryption. Combined with the iommu/vt-d features it should be possible to isolate a hardware device from reading all ram, just the buffers that it should be able to access. Thatll come with a performance hit (based on current hardware being used for VM gaming, maybe about 10%ish at worst) but it would be acceptable for security if that level of attack is something you want to guard against.

Aren't IOMMUs supposed to be able to prevent e.g., a NIC from having access to any RAM other than what the OS grants it?

RISC-V is Open Source.

Will the RISC-V based CPU in your computer be Open Source?

A parallel example is while WebKit is Open Source Chrome isn't

Correction: RISC-V is an Open Standard.

Of course there will be both proprietary and open implementations of RISC-V.

So what are the chances that you'll be able to get an open standard RISC?

Unlike software, you can't just download the code, you have to pay for a fab

Right now there are open implementations that have been taped out into chips and various open FPGA implementations, but nothing for sale. lowRISC seems like the most promising open RISC-V implementation for that.

http://riscv.org/ http://lowrisc.org/

Apparently they estimate there will be a Raspberry Pi equivalent for RISC-V in about a year (whole talk worth watching):

https://youtu.be/QTYiH1Y5UV0?t=39m20s

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) ?

I have a feeling Intel is more likely going to consider this a "vulnerability" and try to close it off in the next revision...

Anyone who works there, has access to the required information, and is unhappy at the situation surrounding ME and other freedom-hostile directions your company is taking, you know what to do!

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

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.

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

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.

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

How does a userland process communicate with a PCI device?

Asking for a project.

Take a look at the /bus/pci section of sysfs: https://www.kernel.org/doc/Documentation/filesystems/sysfs-p...

I was more interested in Windows but thanks.

Does that mean if you have a secondary network card the risk goes away? (genuine question).

It depends how paranoid you are. AMT/vPro requires an Intel NIC but in theory NSA firmware could talk to any device.

So that’s why my Intel NIC never really worked well, and two devices showed up in my router as connected?

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

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?

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.

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

How do you think it accesses the network? In fact, I don't think every version has network support in the first place.

It is designed for remote management of a computer. Take your best shot, do you think it has network support? Also, it doesn't need for the computer to be powered on. One of the advertised features is remote HDD wipe, in case your laptop is stolen.

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

+1 for the use of ifdtool.

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?

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/

2. http://arstechnica.com/gadgets/2008/01/via-cpu-isaiah/2/

Any research on how to disable AMD PSP.

What if I like using the integrated NIC?

Just reboot after neutralization.

"With ME neutralized, the MEI interface disappears from the PCI bus, and the integrated NIC ceases to work, but will resume to work after a reboot."

The phrasing there is confusing. Does the NIC break because the ME is neutralized? Then rebooting again with the ME neutralized will break the NIC again.

Why would the NIC only break once after the ME is neutralized? The system is started from a fully powered-off state after the ME firmware is updated. Maybe the NIC has some sort of non-volatile state that gets updated when the ME fails to initialize, and then the NIC starts working again. That's the most complex explanation so I thought it unlikely, but I'm happy to hear more from someone who has actually neutralized their ME.

Check Federico's reply here https://www.coreboot.org/pipermail/coreboot/2016-November/08... tl;dr: power cycle (power off and then turn on, not just reboot) your PC after the ME neutralization.

It seems to be that the ME takes exclusive control of the NIC, and controls it.

After a reboot, the NIC starts without the ME ever taking control of it, so it works.

Apologies this is interpretation not actual experience, so grains of salt.

It's not strictly clear to me, but reading through what they're doing, the ME isn't re-engaged or its unclear how it recovers itself.

Unless the ME is operating with a recovery binary somewhere that isn't covered by Nicola's neutralizer and the subsequent flashing, I don't think it comes back in to normal operation.

This was confusing to me as well. I'm parsing this as the NIC doesn't work after a cold boot, but does after a warm boot.

Your interpretation is correct. I am going to fix this ambiguity.

Now the ambiguity get fixed, with YOUR words. English is not my mother tongue.

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

If the solution to ME stealing my secrets is simply "don't plug in a network cable" then that's a lot simpler and I'm not going to bother with the potential brick making. Why go through all this and still not have a working computer?

Can you elaborate?

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

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

Reply on news.ycombinator.com