I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. The cynic in me thinks that this will change absolutely nothing.
There is a great website called The Bad Thing  that has compiled the known information about Intel ME.
I just ran the detection tool on my laptop and I am running a vulnerable version of Intel ME, but I can't even do anything about it until my system manufacturer provides a patch for it. I feel like this is going to be one of those situations that ends up leaving millions of devices unpatched and vulnerable a few years down the road.
I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there.
In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal users for remote administration as well.
But it needs to be secure, and it needs to exist without secrecy. If this portion were free for the user to configure, or if they allowed complete disabling via motherboard jumper, or simply open sourced it, that would be a better step.
However, the NSA's activities have destroyed all trust in these sorts of features coming from an American company, so even if it were completely open sourced, there's no guarantee that there isn't other hardcoded ROM also executing in tandem with the open source components.
> If they were more transparent, then they could be used by normal users for remote administration as well.
The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. There aren't even any robust specifications for it (like those for ISAs); it's literally a black box -- and one granted terrifying access to both the system's internals and external network interfaces.
It's 10PM. Do you know if your ME has been provisioned by evil malware?
I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. It's not an innocent housekeeping microcontroller, it's one hell of a remote-access-tool, plain and simple. That intelligence agencies have demanded that Intel provide a bit to neuter the ME after its bringup is testament to that.
My personal computer isn't part of an enterprise/corporate network, and I don't want any RAT (nor an auxiliary CPU with network access that is waiting to be provisioned to act like a RAT) installed on it, the same way my house-lock isn't keyed with a master key that the police holds.
I (and most other end-users) do not need any sort of remote-management capability. We need trustworthy and robust computers that are capable of not leaking secrets and losing control to adversaries -- and "remote management" hardware is a severe step backwards from that.
Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying to distance yourself from it. Maybe you don't like the words "non-libre" or "proprietary" but you certainly seem to be arguing for the same thing that they are arguing for.
> I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function.
Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want.
Again, maybe you don't like the way people argue for it, but you're arguing for the same freedom that others want.
1. you cannot disable it completely - there's an image of Intel ME, burned into the chipset, which checks for the presence of the ME + AMT in the SPI flash, and it checks for signature. (There's an exception to this, with skylake and above)
2. you cannot run a modified or reverse engineered version of it, unless you have Intel's private key to sign your own binary.
Basically the hardware is tivoized.
Access to the firmware binary running on the ME processor and documentation for the latter would be even better than having source, since the latter assumes you trust the toolchain too.
That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.)
All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonomously by the PCH these days, with the CPU just asking the PCH to "get it done." And the logic that runs in the PCH to interpret those requests and decides when and how to apply them, is executed by the ME.
The ME only managed to not exist previously, because mainboards were previously both "simpler" (every bus spoke exactly one protocol and the controller chip for that bus did the protocol signalling) and more complex (tons of single-purpose controller chips.) The PCH boils all that down to one chip, and it needs a CPU to do it, and that CPU is the ME. Getting rid of it would mean going back ~15 years in computer capabilities.
(Another way to think of the PCH is that it's basically an SoC chip, with the "heavy lifting" of application execution moved out to a separate, upgradable CPU socket. But, like any SoC, it still does need some sort of internal CPU. The ME is that CPU.)
> That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.)
Then how does Intel disable it for governmental customers (high-assurance)?
Though the ME currently performs some complex early initialization tasks, the notion that a modern x86_64 platform simply cannot work, or cannot work efficiently, without the ME running indefinitely/alongside the OS is plainly wrong.
I concur. Also regarding: ACPI, there often is an auxiliary microcontroller used to do power management and keyboard interfacing called "embedded controller" (sometimes there's also a mysterious ASIC, part numbers for them include Rohm BU77700KVT Toshiba TB62D515FG,TB62501F) that lives on some SMBus and with which the ACPI implementation, running on the main processor, talks with.
Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity entirely.
Then we can worry about something else, which is secretly embedding mini-CPUs into the CPU itself.
There are tons of processors in modern systems. Most separate chips for controlling sub-systems have them, like DRAM, NICs, USB, keyboards, monitors, storage devices, video cards, etc...
The reasons are performance and flexibility - when separate components act like remote hosts, the device manufacturer can divide up work between the OS driver (main CPU) and target system as desired.
Now, on many motherboards the BMC stuff will aggressively talk in-band even if you think you've disabled that.
I would carefully analyse if patching is a good thing.
Those vulnerabilities might be used in good way to disable ME and all this intel crapware completely, while if patched, this again may be impossible without doing manual chip clip and reprogramming with external device. Of course YMMV.
Here, nice read of current way, using raspberry pi and clipping ME chip while motherboard is off:
No need to salivate over something that you paid for and that you already used for 8 years.
Post-Snowden if you believe the NSA has already broken into most things and has very often paid to facilitate this (like loss-making Skype US server routing, or inefficiently using valuable silicon space for IME), you are no longer a conspiracy theory lunatic - you are just a mere sane person applying Occam's razor.
I don't think it's necessary to pay when you can just threaten charges of treason (Melissa Mayer) or make an example out of the uncooperative (Joe Nacchio).
Our brightest hope for reform involves (a) a breach involving ME and (b) European regulators laying fines on Intel.
They clearly invested some serious money into this sort of thing and see it as a differentiator (or AMD wouldn't have followed suit). Chances that they'll throw it all away because of a few vulnerabilities are very, very thin.
According to the small footnote at http://www.amd.com/en-gb/innovations/software-technologies/s... AMD does not use the name "Platform Security Processor (PSP)" anymore, but calls it "AMD Secure Processor" instead.
I'd still consider AMD the better player in the game.
Maybe, but they'll only complain for about five minutes. Then, they'll patch everything and move on and forget about it.
Until the next time. Rinse and repeat.
Intel managed to make PCs as safe as Android.
Do we really think older systems are magically not vulnerable to any of these? It seems more likely that they're vulnerable but old enough that they're getting ignored... and so they'll never get fixes.
Intel sales slump solved? :-/
Of course as it becomes clear you can (and should) disable it, if you do that on a corporate laptop you might find that your IT team is both mad and proud of you at the same time. Quite the quandry.
Are you really suggesting the IME and AMD's similar component are not the fruit of a collaboration between these market dominating companies and the NSA?
> "Potential Impact: An attacker could load and execute arbitrary code outside the visibility of the user, operating system, and hypervisor/virtualization platform; resulting in exfiltration of secrets, subtle manipulation of system operation, or denial of service."
Now you need wimlib to create the WinPE image: "mkwinpeimg --windows-dir=/mnt winpe.img --overlay=$HOME/.wine/drive_c/DRIVERS"
The resulting winpe.img can be dd'ed to a USB thumb drive. Boot into it, and execute "cd /WIN/AMT/HECI_REL/win10", "drvload HECI.inf" (to load the MEI driver) and then "cd /WIN/ME/", "MEUpdate.cmd" to update the ME firmware.
# modprobe mei_me
# modprobe mei_txe
# modprobe mei
# lsmod | grep mei
mei_me 36864 0
mei_txe 20480 0
mei 86016 2 mei_me,mei_txe
# python2 ./intel_sa00086.py
INTEL-SA-00086 Detection Tool
Copyright(C) 2017, Intel Corporation, All rights reserved
Application Version: 220.127.116.11
Scan date: 2017-11-23 20:37:48 GMT
*** Host Computer Information ***
Manufacturer: Apple Inc.
Processor Name: Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
*** Intel(R) ME Information ***
Engine: Intel(R) Management Engine
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is not vulnerable.
When the HW dies, I'll most probably go for a Chromebook with Coreboot - and install Debian on it.
I've had it - enough with this idiocy from Intel and AMD ; if they can't see how these "signed black boxes" are harming them, they deserve what's coming (open, and powerful enough architectures - i.MX8, RISC-V, etc).
It's unclear to me whether or not Apple uses Intel firmware for the non AMT portions of ME. I will report back to you when I find out. However, the evidence I've seen so far isn't looking too good, and it definitely looks like the vast majority of macs made in the last 5 years are all vulnerable, many appearing to run outdated Intel firmware to boot -- not good for Apple.
The evidence can be seen here,
where some people run a python program to check the version of their ME firmware (which works and returns numbers completely consistent with Intel firmware numbering). I wonder if Apple just isn't aware of the hack yet?
I'd rather have a more thorough ME test than just AMT I could run though, coupled with a statement from Apple that ME is or will be entirely neutered on Macs in the future.
Plus, purchasing machines like that one not only sends a clear signal that we want backdoor-free computing, but also allows the further development of more libre computing options. Wouldn't you rather have Linux and BSD as first-class citizens on new hardware, instead of always needing to play catch-up from behind?
Q: Why preorders? Why can't I evaluate a production machine right now?
A: Although we have Talos™ II hardware in our labs, IBM has not yet released the POWER9 CPU to the general public. The POWER9 launch is scheduled for Q4 this year; we intend to make Talos™ II available to everyone shortly after POWER9 launch via our pre-order model. This model allows us to manage supply of the Talos™ II systems for Q4 shipment, and we intend to transition to a more standard ordering model once the POWER9 processor has reached general availablility (GA). Orders placed after our pre-order cutoff will not ship until 2018, and you would be missing out on the benefits of early market access to the POWER9 processor, so we strongly recommend that you place your pre-order as quickly as possible!
Several HN users here (beefhash, jlgaddis, joe_the_user) have raised the possibility that applying the patch might make it impossible to get rid of the Intel ME entirely.
If you don't apply the patch, someone may come up with a nice new exploit (using the security bugs) to completely remove the Intel ME.
If you do apply the patch, it might close off possible exploits and you'll be left with an Intel ME that's impossible to remove.
Maybe there is a way to reprogram to disable ME without the flash programmer which these fixes may block. If my laptop weren't already ME disabled, I'd probably apply the fixes.
Isn't there an "eFUSE-like" counter that prevents firmware rollback?
Feel free to join.
The question is what the best IRC server would be to use; considerations include reputation and "unpopularity", ie certain overly busy networks may scare some people away.
There's also the possibility of using Discord.
The main issue is encryption; most won't have any opinions on the subject, but more vocal types who may be useful to have on board may insist on specific forms of security in order to participate.
Just my 2c
“Critical: A vulnerability, which if exploited, would allow remote execution of malicious code without user action.”
“Important: A vulnerability, which if exploited, would directly impact the confidentiality, integrity or availability of user’s data or processing resources.“
"Asking for a friend"
edit: maximum downvotes for a legitimate question, thanks all
The same is true of all the devices directly integrated into your motherboard. Broadcom/Intel wireless chipset, Ethernet, audio, etc.
Customer. Or customers (plural)??
I ask, because I assume this amount of complexity wasn't created because it was cheap, or end-users were crying out for it. There may be other customers -- those with three-letter agency names, who would wish for code to run on the computer you possess (note, I did not say "own", so long as someone else has control).
It's getting too easy to be this paranoid. Besides, it was fun when I sounded crazy. Now it's alarming.
Now that doesn't mean that the TLAs haven't found and used a vulnerability but that's like everything in a computer.
I'm not familiar enough with the Intel ME to tell, but could this possibly be exploited with the arbitrary code execution in the ME being used to set the HAP bit without requiring hardware intervention?
Maybe I'll hold off on patching for a bit.
I think you're suggesting extremely interesting but I'm not totally clear on it. So someone has come up with some code to either disable (kill switch) or remove the Intel ME. (Setting the HAP bit is the kill switch.)
Now Intel and its vendors are going to issue a patch for the Intel ME. Are you saying that as a result of applying this patch we might not be able disable or remove the Intel ME? In other words, we'll end up with a slightly more secure Intel ME, but be worse off since we can't exploit any bugs to get rid of it?
If I'm understanding you correctly, this sounds like the iPhone situation: upgrade to a newer iOS and lose the ability to jailbreak.
Hold off on patching this vulnerability so that it can be exploited later in order to disable ME entirely. Their firmware updates could very well close off these existing "known holes", making them impossible to exploit.
If we can take advantage of them to kill the ME entirely, that's even better than Intel releasing this fix.
$ sudo ./intel_sa00086.py
*** Risk Assessment ***
Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
If you have a Lenovo machine, check Lenovo's security advisory  to see if it is affected. Intel has the wrong URL in their link.
Edit: FWIW, the (Linux) tool creates a .log (and .xml) file in the current directory that was slightly more helpful:
$ tail -n 4 SA-00086-cluefire-2017-11-20-21-09-36.log
HECI error: No device with MKHI found
Can't find SPS version in the tool output
Error 9460: Unknown or unsupported hardware platform
Most annoying thing is that there isn’t even a real alternative. If I understand it right then AMD chips have pretty much the same thing?
I am really looking forward for either ARM to displace x64 or even better RISC-V. With ARM you have many more vendors so more chance for options, and RISC-V is the ultimate in openness.
i.MX8 will soon be released in quantity to the public and it is claimed by people who experimented with testing samples of it that it is similarly open as the i.MX6 in this sense.
As someone who has spent ~four years working on software for a single M4F, that reads like "it's a datacenter on a chip", more or less. It's ... big.
It also has dual-gigabit Ethernet, USB 3.0, USB 2.0, and enough other low/medium-speed serial interfaces to make you go dizzy. :)
I wonder what the pricing will be.
ARM could be a affordable alternative to x86 if that works for you.
Even the open source friendly Raspberry Pi relies on proprietary blobs and proprietary firmware, with vast parts of the documentation only being available to system integrators (meaning: not you) under an NDA.
Theirs is a Broadcom chip, but my understanding is that the scenario is pretty much the same for other ARM vendors. If the chip is anything more complicated than your average 8-bit micro-controller, expect it to be running some kind of "system" which is, of course, closed source.
I may be wrong, but my impression is that a lot of the other ARM boards out there have the ARM chip as the main CPU, and without a management chip watching it. In any case, a board like that, or a Pi with a reverse-engineered firmware blob (currently in development) would be better than the Raspberry Pi as it is now.
Broadcom (producer of the chips used on the RPi) and open source friendly? A sense an oxymoron.
The tool rightly points out that my desktop consumer system is vulnerable (from the list, no Intel CPU manufactured in the last 5 years isn't), then suggests I contact the manufacturer for an update. Here is what the tool says my system manufacturer is:
Manufacturer: To Be Filled By O.E.M.
Model: To Be Filled By O.E.M.
Some of the board vendors do a better job, but usually still not as good as "namebrand computers." There is a lot of engineering work that goes into integration. It's not readily visible to endusers/consumers and therefore difficult for us to appreciate it or evaluate it for completeness or accuracy.
I hope that someone does a survey of computer and board vendors' support for this problem. I would like to see who abandons products last.
If Intel actually cared about your security they would document that. It says so right in the security advisory that the external researchers are the reason for the security review, and not due to customer concerns.
However, Intel's own platform tools (MEInfo and MEManuf running in a UEFI shell) can't even communicate with the ME on my 2015 Macbook Pro, so I would be quite interested to know what exactly they have done differently with regard to configuring the platform.
People have been archiving every version of the ME firmware for each chipset, and it would appear there are some versions that may be specific to Apple hardware. I'm not sure what is different, if anything, but you can see (and download) the particular firmware versions here: https://www.win-raid.com/t596f39-Intel-Management-Engine-Dri...
The Intel dudes could have added "from future import print_function" and made it version-independent.
I'm just waiting for the ransomware that lives on AME, and is burned to the various dies instead of on hard-drives. Isn't that what this open door means?
I almost wish it covered 3rd-5th generation, just to help me push some folks to upgrade.
It’s still not really clear to me why it needs to exist at all.
That _can_ include advanced power management, secure computing stuff, watchdog functions and stuff like that.
Based on the analysis performed by this tool: Detection Error: This system may be vulnerable, please install the Intel(R) MEI/TXEI driver (available from your system manufacturer).
Does that mean that the Intel ME is disabled, so I don't have to worry about it? I certainly don't want to install anything that might enable the Intel ME if it's already disabled!
What a quandary. This reminds me of all the information I was asked to give to get a detailed credit report. If I didn't give it, they weren't going to give me the report. If I gave it, they would add to my credit file even if they never had it before.
Basically you have to trust the compiler because it compiles all code on your system, including itself. Not entirely the same, and I think the Intel trick is more nefarious.
As I understand it, the ME subsystem is an overseer, and is running even if your main PC is powered off. It has control over the network, unobservable from the downstream CPU/OS. It could therefore receive commands/input from the network and update itself while "off", or transmit data outbound. So unless the system is unplugged from the wall, the ME subsystem could be doing God-knows-what.
A vulnerability where someone can remote control your machine even after you swap out all local storage and install a new OS is another thing entirely.
Who knows what benefits this defect can give you down the line. Maybe it will be possible to take over the entire Management Engine. That would be neat.
They will of course not let go because it's a backdoor. It's an overprivileged computer within your computer.