For a long time there was a commonly held belief that open source products were inherently more secure because there was nothing hidden. The thought was that with the code for popular applications out in the open, there’d be scores of good guys looking at every line and bugs and flaws would be few and far between.
Alas, this turned out to be a pipe dream because even the most examined code can still contain flaws so obscure and arcane, even highly skilled and incredibly talented coders can’t find them. Why? It’s usually because the good guys don’t have the time to play hacker as intensely as the real hackers do. For the bad guys, the rewards for finding exploitable flaws are tangible while for the good guys, the cost of not finding flaws far exceeds, by orders of magnitude, the value of the few flaws they do find because those flaws are the most easily found.
Even so, having code out in the open has huge benefits for the user community because while it doesn’t prevent exploits from being discovered, it also avoids the problem of companies with locked-down, proprietary code hidden through obscurity not admitting when said code gets exploited; something that, sadly, is almost a certainty given the potential brand damage of any admission of any kind. Indeed, even when the company has a team dedicated to protecting the integrity, and therefore the marketability, of whatever the code does or supports, that team can never be as far reaching as an open source community can be and certainly never as devious as hackers can be.
In short, open source rather than obscurity is the best answer to countering exploits so it was seriously depressing to learn that Intel, a company you would expect to know better, have included a control subsystem on recent X86 processors called the Intel Management Engine (ME) that you can’t examine, control, test, or disable ... at least for now.
The [Intel] Management Engine (ME) is an isolated and protected coprocessor, embedded as a non-optional part in all current (as of 2015) Intel chipsets. According to an independent analysis by Igor Skochinsky, it is based on an ARC core, and the Management Engine runs the ThreadX RTOS from Express Logic. According to this analysis, versions 1.x to 5.x of the ME used the ARCTangent-A4 (32-bit only instructions) whereas versions 6.x to 8.x use the newer ARCompact (mixed 32- and 16-bit instruction set architecture). Starting with ME 7.1, the ARC processor can also execute signed Java applets. The ME state is stored in a partition of the SPI flash, using the Embedded Flash File System (EFFS).
The ME has its own MAC and IP address for the out-of-band interface, with direct access to the Ethernet controller; one portion of the Ethernet traffic is diverted to the ME even before reaching the host's operating system, for what support exists in various Ethernet controllers, exported and made configurable via Management Component Transport Protocol (MCTP). The ME also communicates with the host via PCI interface. Under Linux, communication between the host and the ME is done via /dev/mei.
Until the release of Nehalem processors, the ME was usually embedded into the motherboard's northbridge, following the Memory Controller Hub (MCH) layout. With the newer Intel architectures (Intel 5 Series onwards), ME is included into the Platform Controller Hub (PCH).
A recent Boing Boing article, Intel x86s hide another CPU that can take over your machine (you can't audit it), that revealed the technical details of the ME:
When you purchase your system with a mainboard and Intel x86 CPU, you are also buying this hardware add-on: an extra computer that controls the main CPU. This extra computer runs completely out-of-band with the main x86 CPU meaning that it can function totally independently even when your main CPU is in a low power state like S3 (suspend).
On some chipsets, the firmware running on the ME implements a system called Intel's Active Management Technology (AMT). This is entirely transparent to the operating system, which means that this extra computer can do its job regardless of which operating system is installed and running on the main CPU.
Not only can the ME function when the host processor is in sleep mode, it can also read and write to anywhere in memory without the host processor knowing anything about it and run any code that the ME’s software decides to install.
Now, I know we’re talking about Intel here and those guys are no slouches when it comes to security but with the ME, their reach may have exceeded their grasp. Even though the ME is protected by RSA 2048 encryption, researchers managed to take control of early versions of the system by exploiting firmware weaknesses. As the Boing Boing article points out:
This makes ME a huge security loophole, and it has been called a very powerful rootkit mechanism. Once a system is compromised by a rootkit, attackers can gain administration access and undetectably attack the computer.
I can’t stress strongly enough how bad this is. Anybody involved with computer security will tell you that security through obscurity isn’t security at all and has never worked but that’s exactly what Intel is doing with ME. The consequence will be that no matter how good Intel’s secrecy might be, no matter how good their ME code might be, no matter how strong their encryption might be, the ME will be cracked, hacked, and organizations of all kinds will get whacked. And, in reality, it won't take much:
So, will the Intel Management Engine get compromised? It’s not a question of “if?”, it’s merely a question of “when?”
Comments? Thoughts? Send me some closely surveilled feedback via email or comment below then follow me on Twitter and Facebook. The NSA does, why shouldn’t you?