Intel's zero-day problem

In his talk at FOSDEM 2017, Georg Greve mentioned that every recent Intel CPU contains a second, internal CPU that you cannot audit but which can take over your machine. His contention was that this could be used to do bad things without your consent if it turned out to be treacherous or buggy. As of May 1, 2017, the latter prediction turned out to be worryingly prescient.

Out-of-band management is technology that allows managing a remote server, at all stages of its operation, without having to have an external IP-enabled keyboard, video, and mouse (KVM) device and a remotely operable power strip. It allows a server to be powered off and on, warm and cold rebooted, and gives remote access to the keyboard, video, and mouse once the system is far enough up that the graphics card has been initialized. Without technology like this, if a remote system can't pass its BIOS self-test, has a faulty GRUB configuration, or the kernel panics, someone has to get in a car, often in the middle of the night, and go to a data center to fix it.

In its early days, out-of-band management was accomplished by having a separate piece of hardware inside the server case, often with its own network port, which all had to be configured and connected in order to work. This photo of an IBM Remote Supervisor Adapter (RSA) II shows the VGA cable which has been looped around from the server's graphics card to the RSA card, so that the display can be re-digitized and made remotely available. All this extra hardware was expensive, so the feature tended to be available only on high-end servers. It often needed its own network interface card (NIC), which meant more cabling and switch ports, and more administration.

Intel's Active Management Technology (AMT) provides the same services without any external hardware overhead. It does this by piggybacking on top of the base system's connections, extracting its inputs from and sending its outputs to the system's NIC, usually on TCP ports 16992-16995, 623, and 664. AMT can read from and write to any piece of memory or storage on the machine, and read and write to the screen, without the host CPU being aware this is happening — and therefore, without the host CPU being able to log or audit any of it. Because of the network access, it can send anything it chooses anywhere it wants to, and receive inputs the same way.

Such capabilities are necessary for the AMT to do its job, and network access to the AMT requires authentication. But the AMT is provided by Intel's Management Engine (ME), the "second processor" to which Greve referred. It is present on all Intel's current chipsets, and most of what they've made in the past decade. The ME has total control over the entire system; it is closed and unaudited, and we have all historically been asked to take Intel's word that it is secure.

According to Intel, there is a vulnerability: the AMT can be given remote instructions without an authentication step. This is pretty awful, but it is perhaps not quite as awful as the media coverage is making it out to be. As Matthew Garrett notes:

The drivers that Garrett refers to are those that integrate the AMT and the operating system, allowing the system to pass requests to the ME. Intel calls this the Local Manageability Service (LMS). Fully mitigating the vulnerability requires disabling the LMS if it is installed.

A good first check is to see whether AMT is enabled on your system. To start with, Intel said that the vulnerability "does not exist on Intel-based consumer PCs" For other systems, the company lists four ways of finding out whether a system is AMT-capable; unfortunately, two of them require rebooting the system and interacting with the console. If the system is remote that is only possible if you've activated some kind of out-of-band management solution in which case you already know you have a problem. The other two mechanisms require you to be running Windows. Garrett points out that a Linux system with AMT makes this information available via lspci. Here's some output from one of my vulnerable systems:

    [tom@trouble ~]$ lspci|egrep -i 'mei|heci'
    00:16.0 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #1 (rev 05)
    00:16.1 Communication controller: Intel Corporation C600/X79 series chipset MEI Controller #2 (rev 05)

A non-vulnerable system would display nothing. Garrett goes on to say that even though a system may have AMT, that doesn't mean it's been provisioned, so the system still may not be vulnerable. Since my system does have AMT provisioned, I will need to reboot it, at which point I should be able to disable AMT via the BIOS. Once I've done that, the system will no longer be remotely manageable; for this particular system, that's fortunately not a problem, since I don't manage it remotely. That said, it's an important server and I can't reboot it during the working day, but it's behind a firewall and not accessible on arbitrary ports, so I should be reasonably safe until then. If it was a system that I needed to manage remotely, I'd simply be out of luck; as one of the people from a group (SemiAccurate) that claims it found this bug early—several years ago—said:

This vulnerability is definitely a real and extremely serious problem for people who've been setting up systems with internet-accessible out-of-band management capability and trusting Intel's assurances on access control to keep them safe. Those people have to badger their system vendors for patched firmware that incorporates Intel's changes. Cloud providers and other large-scale virtual-system vendors are probably having a really bad day, scrambling to patch their systems before the black hats get automated exploit tools up and running, which SemiAccurate strongly suspects has already happened. For those whose systems are from smaller vendors, or past end-of-life, or in the worst case self-built or white-box systems, there may be no fix available, and simply living without remote-management capability may be their only choice for the remainder of the lifetime of the system.

For the rest of us, this vulnerability is still a fairly big headache, but it probably isn't the end of the world. The deeper problem exposed by this is exactly the one to which Greve drew our attention: that every system we buy from a vendor who asks us to trust them that it all works exactly as advertised is a system that can cause us great pain if it turns out that the trust was misplaced. This time, we got off fairly lightly. But if the hole had been bigger, for example if a remotely-accessible way had been found to give arbitrary instructions to the ME, that really would look like the end of the world.

That might also be true for similar remotely-exploitable bugs in components like the CPU and the NIC, but we have some chance of catching them in action in the former, and the latter doesn't have anything like the range of access that the ME has. The ME is a black box at the very heart of the system, and that makes it a particularly awful device to be exploitable.

We dodged a bullet this time. If we have any sense, we might insist our vendors stop giving us their assurances that we're protected and start giving us the details and access we need to establish it to our own satisfaction.

Index entries for this article
Security	Firmware
Security	Hardware
GuestArticles	Yates, Tom

---

to post comments