Hacker News new | past | comments | ask | show | jobs | submit login

Aside from applying updates, how else can these vulnerabilities be mitigated? Genuinely curious...



As far as I understand:

* In general you cannot.

* You can try to remove ME with non-official tools like https://github.com/corna/me_cleaner

* Some vendors ship specific laptops with ME disabled (https://fossbytes.com/laptops-intel-me-chip-disabled/)

* For servers or desktops, you can plug in a separate PCI network adapter instead of using the one on the mainboard (please correct me if this is wrong or confirm it as I'm unsure about it). That would at least disconnect the ME from the network by default. But anybody could still walk up to your machine, plug a cable into the mainboard ethernet port and own you at the deepest level.


me_cleaner does not disable the ME. It is a partial disablement of ME functionality, but some functionality remains enabled. The ME firmware is an Intel-signed proprietary binary blob part of which is instrumental in the system boot process, so complete removal is impossible.

me_cleaner and/or the HAP bit, or the services offered by laptop vendors which is basically doing the very same for you, may certainly reduce the degree of attack surface and the extent to which the ME poses a threat, but it is not a complete disablement or removal, and you are still reliant on a non-modifiable binary blob to bring up your system; referring to it as removal is misleading.

Since the firmware is proprietary, it's hard to make any guarantees to what extent a reduced-size ME (via me_cleaner and/or the HAP bit) reduces attack surface in practical terms. My understanding is that even with the HAP bit and me_cleaner applied, the ME continues running at least some functionality after system boot is completed.


This is correct but misleading. The me_cleaner approach, with all options, wipes the entirety of the ME firmware except the module needed for hardware bringup. It then causes the ME to crash as soon as hardware bringup has happened. The host system cannot communicate with the ME processor and the ME processor does not execute any further code after this point. This is the current gold standard.

The next stage would be to disassemble the bringup modules and figure out what exactly they do by reverse engineering, and implement that part independently. People are working on this. So far there is no indication that any of the problematic functionality is in the bringup module.


How can the functionality be implemented independently when the modules must be signed?

Complete reverse engineering could at least serve as an effective audit though.


Nothing requires that the ME initializes the hardware - the BIOS can do so as well. So if the initialization sequence is well-understood the ME can be disabled entirely and the initialization done by coreboot or whatever. This is possible on Intel CPUs. Unfortunately on AMD it doesn't work as unless the secure coprocessor clears the reset lines the other cores cannot wake up.


It seems likely, to me anyway, that the CPU doesn't have any effective way of verifing what is running on the ME. So reversed firmware could just lie to the CPU and tell it that its firmware is signed when it isn't. A similar approch is use the microg project to replace proprietary google play services by spoofing google's signature.


This is very difficult to do as the bit that loads the modules (and checks the signatures) is implemented in hardware.


At this point ME should simply be considered malware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: