> 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?
* 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.
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.
>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'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.
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.
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?
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?
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.
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.
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.
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.
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?