Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

hardenedlinux.org

Post reply on HN
Print view View original

71–80 of 81 posts

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#71

Post by qb45 »

sounds wrote: post #18
bsharitt wrote: post #12

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 wh…

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#72

Post by pgeorgi »

tunesmith wrote: post #43
sounds wrote: post #4

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…

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#73

Post by tonylemesmer »

wmf wrote: post #27
phantom_oracle wrote: post #19

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

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

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#74

Post by yrro »

jakobdabo wrote: post #44
snvzz wrote: post #3

The ridiculous shit that needs to be done just to rid of some blob. RISC-V can't take the market over fast enough.

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 w…

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?

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#75

Post by sounds »

tunesmith wrote: post #43
sounds wrote: post #4

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…

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/

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#76

Post by sounds »

tscs37 wrote: post #70
therein wrote: post #66

Earlier quoted context omitted.

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#77

Post by wmf »

tonylemesmer wrote: post #73
wmf wrote: post #27

Earlier quoted context omitted.

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

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#78

Post by jtl999 »

jdiez17 wrote: post #68
jtl999 wrote: post #58

Earlier quoted context omitted.

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#79

Post by igor_sk »

sounds wrote: post #75
tunesmith wrote: post #43

Earlier quoted context omitted.

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/

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#80

Post by igor_sk »

kevin_b_er wrote: post #40
yuhong wrote: post #22

Earlier quoted context omitted.

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

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…

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