Live data from Hacker News

Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

hardenedlinux.org

61–70 of 81 posts

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#61
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…

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

# shutdown -r now

?

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#63

Earlier quoted context omitted.

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/

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#64

Earlier quoted context omitted.

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#65
post #30
post #5

Earlier quoted context omitted.

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#66
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…

> 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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#67

Earlier quoted context omitted.

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.

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#68
post #58

Earlier quoted context omitted.

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

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

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#69
post #59

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

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

Thanks

Re: Neutralize ME Firmware on SandyBridge and IvyBridge Platforms

#70
post #66

Earlier quoted context omitted.

> 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

Post reply on HN