Hacker News Reader

Comment by nailer | Hacker News Reader

> how to disable Intel ME, which is accomplished by sending an HECI (Host Embedded Controller Interface) command in the same way it has been for ages.

I didn't know this - so it's possible to turn off Intel ME? The idea of a full copy of Minix with TCPIP running on my machine is scary. Can someone else turn it back on?

View on HN

Yes. There are several ways, depending heavily on the version, and ranging from most trustworthy to least trustworthy:

* By patching the ME firmware itself - see the me_cleaner project, and methods documented here: https://puri.sm/posts/deep-dive-into-intel-me-disablement/ . This is Pretty Reliable; the runtime code has been deleted from flash.

* By setting a bit in the flash configuration, assumed to be added for the US High Assurance program: https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bi... , https://www.ptsecurity.com/ww-en/analytics/disabling-intel-m... . This is Mostly Reliable; the mechanism has been fairly aggressively reverse engineered and was added for a program with strict requirements.

* By sending an HECI command that says "hey ME, turn off your runtime" https://review.coreboot.org/c/coreboot/+/52800 . This is Somewhat Reliable; the method is well understood and seems to work but I'm not sure someone has done a deep dive audit into whether it could be re-enabled somehow.

Do we have anything equivalent for AMD’s PSP?

The equivalent of Option 3, send a supported command that tells the runtime capabilities to shut down, has been provided as a user-selectable option by AMD in AGESA (the unified AMD BIOS/EFI package) for several years now.

I haven't found anyone who has actually reversed the functionality to audit what it's doing, though.

In a way this is all insane: we are spending a fortune on security globally but at the same time manufacturers get to insert massive backdoors into the hardware and hardly anybody bats an eye.

What if... ME/PSP are actually very low security risk relative to everything else in the system.

It's troubling to have even a potentially very low security risk in hardware I paid for being beyond my reach to resolve.

>manufacturers get to insert massive backdoors into the hardware

There is no proof that they are

>hardly anybody bats an eye.

Because only a certain niche of paranoid people are willing to believe that companies are trying to make their systems intentionally insecure so that you can be personally hacked.

It most certainly doesn't have to be intentionally insecure but it almost definitely is accidentally so. There should be no OS nor network stack running in the firmware, period.

User-respecting OS running in the firmware can be really useful. It must be FLOSS though. Example: https://puri.sm/posts/pureboots-powerful-recovery-console/.

It's a fact that NSA solicits companies to add security weaknesses to their products. They'll "make an offer you can't refuse" by offering cash (in the form of a contract), and they'll use their influence with other "contractors" and government agencies to punish companies that don't participate.

This is not unique to NSA. Security agencies within other governments play the same games with supply chains.

Intel making their products insecure is bad for their brand and bad for world wide computer security. Massive amounts of damage could happen by abusing such a backdoor. There is plenty of evidence of Intel claiming that there are no backdoors in their products, but there isn't for some NSA deal for adding a backdoor.

Pardon? Snowden showed huge amounts of NSA backdoors. It’s probably worth limiting the conversation to what they don’t have access to rather than trying to enumerate what they do have access to.

You must have slept through Snowden.

That is not an argument. You can't justify that everything is secretly backdoored because of some old leak.

The safe assumption is that if there is a computer sitting on your LAN that you don't have access to that has access to your stuff that you have a massive security issue in waiting. That it hasn't materialized yet doesn't mean a thing and there are plenty of documented security holes associated with the ME, and likely many more that you simply will never know about. This stuff has been chewed to bits on HN and elsewhere.

If you feel different that's fine but with security the old adage 'better safe than sorry' applies very much and given the data collected so far the evidence of 'some old leak' times n is rather more solid than your belief in the opposite. FWIW Intels claims that they would not cooperate with the NSA are worth absolutely nothing because the USG has the power to tell Intel to stay quiet about such a deal.

If CISCO could be influenced by the NSA then so can Intel, either through supply chain interdiction or through more direct means. But to categorically claim that this is an impossibility is nonsense, the relevant questions are (1) has it been done? and (2) how would we ever find out given the locked up status of the ME? and (3) who past Snowden would be brave enough to leak the evidence if it exists?

This is probably going to change when AMD switches from AGESA openSIL, fully open firmware.

> The idea of a full copy of Minix with TCPIP running on my machine is scary.

Well...

- I don't think the ME knows how to talk to non Intel NICs (install a Realtek or Broadcom based NIC).

Some searching I just did regarding "AMT" (remote management feature that uses the ME) says it needs an Intel NIC.

And, some searching I just did regarding vPro (not 100% sure what this is exactly) says vPro uses the onboard network adapter.

- So I don't think the ME will look for a NIC on the PCIe bus at all, but not 100% sure.

- I'm fairly sure AMT/vPro/the ME doesn't know how to talk to anything other than stuff on the PCIe bus (use a USB NIC)

- The NIC the ME would use has a MAC like any other NIC. Should be information available from the firmware. Just block it at the router.

I would like to know how the ME shares the NIC with the user OS on these systems. Do they have a completely separate interface that somehow uses the same physical port? Do the drivers from the two operating systems cooperate? Do they have one MAC address or two? What happens if the user installs a PCI NIC and doesn’t plug in the onboard interface?

It definitely only works with certain Intel NICs. It doesn't require OS cooperation because the main purpose of AMT is to recover a broken OS. I think the NIC effectively has two host interfaces so that one can be used by the OS and the other can be used by the ME. Due to network authentication and such I think the same IP and MAC address is shared by the OS and AMT which is of course a rampant layering violation.

> It definitely only works with certain Intel NICs.

Not really doubting you as that kind of stands to reason to me, but is there any proof of this? The whole thing seems opaque.

I think the general idea is that the purpose of having networking in the ME is to enable certain features, which are documented to only work with certain Intel NICs. Of course if you are paranoid, you would not trust this to stop a determined attacker.

Will it have access to a wifi card? Only Intel?

Yes, AMT works over Intel WiFi.

Raising yet more questions about how AMT participates in enterprise WiFi authentication schemes. My laptop at work has a computer certificate which works for the OS, but how does AMT have credentials or even know which SSID to associate with?

This is all available in the Intel AMT documentation. While the implementation is closed-source and opaque, this isn't some magic functionality, it's a product that businesses want and use.

If the OS is running, wireless AMT forwards packets through the OS driver; it's cooperative (unlike the wired AMT, which always exists at a higher level than the OS, because it has features like resetting a crashed OS).

If the OS isn't running, you provision the AMT with WiFi credentials for the AMT host, using a tool. If you want, you can use the Local Manageability Service (LMS) tool to automatically forward credentials from the OS to the AMT, otherwise, you can install specific profiles.

I have bitter memories about AMT and all this "remote management by Intel" from the old days.

When I'd built my first home server/NAS I wanted remote control but I didn't want to pay for hardware with real IPMI/iLO/..., so I choose desktop motherboard from Intel with Q35 chipset (it was time when Z45/Q45 was cutting edge and 35th series was previous generation). NIC was Intel's one too, I think it was legendary PRO/100, not 1G yet.

I was VERY disappointed to discover, that I didn't get remote console and/or remote serial port with ME/AMT at all, that it i not true AMT in desktop motherboards, even with Q chipset.

The hardware has the ability to tag packets with certain contents - this is used for more interesting Wake-on-LAN policies (eg, rather than requiring a magic packet, you could have a web server that aggressively suspends and then gets automatically woken when there's an incoming packet to port 80 or 443). In the AMT case, it identifies incoming packets that are aimed at the AMT ports and passes those off to the ME rather than the OS. If you want to speak to AMT from the host OS, you install an app that listens to those ports on localhost and then tunnels the traffic through the HECI interface instead. There's only one IP address and one MAC address, and it's limited to built-in Intel NICs.

Alternatively, you can set the HAP bit in the BIOS flash https://hackaday.com/tag/hap-bit/

Reply on news.ycombinator.com