SoylentNews is people
SoylentNews
from the One-ring-to-bring-them-all-and-in-the-darkness-bind-them... dept.
From Damien Zammit, we have this fun little tidbit:
Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they'll expose all affected systems to nearly un-killable, undetectable rootkit attacks. I've made it my mission to open up this system and make free, open replacements, before it's too late.
The Intel Management Engine (ME) is a subsystem composed of a special 32-bit ARC microprocessor that's physically located inside the chipset. It is an extra general purpose computer running a firmware blob that is sold as a management system for big enterprise deployments.
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.
The purpose of AMT is to provide a way to manage computers remotely (this is similar to an older system called "Intelligent Platform Management Interface" or IPMI, but more powerful). To achieve this task, the ME is capable of accessing any memory region without the main x86 CPU knowing about the existence of these accesses. It also runs a TCP/IP server on your network interface and packets entering and leaving your machine on certain ports bypass any firewall running on your system.
Yeah, and I'm sure they pinky-swear never to allow the NSA access to any computer via it. I'll be using AMD from now on, slower or not, thanks.
(Score: 2) by TheRaven on Monday June 20 2016, @03:11PM
If you're running an x86 chip, then worth worrying about this shows remarkable misplaced priorities. The x86 instruction set includes a large number of instructions that are too complex to implement as pure hardware (along with some other features, such as transactional memory). These are implemented in microcode. You can update the microcode yourself, however the microcode (effectively firmware) is machine code for an instruction set that (unlike the ARC32 that TFA gets worked up about) is completely undocumented outside of Intel and changes between revisions. This means that, whereas you could disassemble the ARC32 code and figure out what it is doing, it is basically impossible for anyone outside of Intel to know what the microcode is doing.
If you look at the errata sheet for any recent generation of Intel chip, you'll see over a hundred known bugs in the microcode (most patched, some worked around by disabling features), many of which are security critical. I recall several microcode bugs that have allowed unprivileged code to overwrite kernel-owned memory that happens to be in the cache (including one in Haswell). If, hypothetically, Intel were to provide the NSA with access to the details of some of these vulnerabilities, then it would be fairly simple for them to write attacks that could run in the browser and gain full kernel privilege.
But, by all means, get worked up about the simple processor with a well-documented ISA that can turn on and off the black box on your desk.
sudo mod me up
(Score: 2, Informative) by pTamok on Monday June 20 2016, @05:33PM
You are doing a remarkably good job of misdirection here.
Yes, there are microcode bugs, and yes, the microcode is updateable too.
1) The bugs will vary across processors, making the vulnerability different from processor to processor, unlike this one-size-fits-all solution. Of course, the NSA could well have a stockpile of vulnerabilities for all the different processors out there.
2) The fact that the same issue affect microcode as well means that really, people should also be looking at the microcode update mechanism as well. The fact there is another problem vulnerability that is potentially just as bad does not warrant ignoring the first vulnerability. Two wrongs do not make a right. It even points up that more work should be being done on formally verifiable hardware under owner control.
I am well aware of the capabilities of microcode update. I worked with someone who rewrote VAX microcode to enable faster processing of geological data for oil drilling. The ability to rewrite microcode is very powerful. It is reasonable that updating the microcode should be capable of being under the control of the person who bought the hardware, just as remote management should be.