/ Damien Zammit / 5 am Wed, Jun 15 2016
  • Submit
  • About Us
  • Contact Us
  • Advertise here
  • Forums
  • Intel x86s hide another CPU that can take over your machine (you can't audit it)

    Intel x86s hide another CPU that can take over your machine (you can't audit it)

    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 unkillable, 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.

    While AMT can be a great value-add, it has several troubling disadvantages. ME is classified by security researchers as "Ring -3". Rings of security can be defined as layers of security that affect particular parts of a system, with a smaller ring number corresponding to an area closer to the hardware. For example, Ring 3 threats are defined as security threats that manifest in “userspace” mode. Ring 0 threats occur in “kernel” level, Ring -1 threats occur in a “hypervisor” level, one level lower than the kernel, while Ring -2 threats occur in a special CPU mode called “SMM” mode. SMM stands for System-Management-Mode, a special mode that Intel CPUs can be put into that runs a separately defined chunk of code. If attackers can modify the SMM code and trigger the mode, they can get arbitrary execution of code on a CPU.

    Although the ME firmware is cryptographically protected with RSA 2048, researchers have been able to exploit weaknesses in the ME firmware and take partial control of the ME on early models. 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.

    On systems newer than the Core2 series, the ME cannot be disabled. Intel systems that are designed to have ME but lack ME firmware (or whose ME firmware is corrupted) will refuse to boot, or will shut-down shortly after booting.

    There is no way for the x86 firmware or operating system to disable ME permanently. Intel keeps most details about ME absolutely secret. There is absolutely no way for the main CPU to tell if the ME on a system has been compromised, and no way to "heal" a compromised ME. There is also no way to know if malicious entities have been able to compromise ME and infect systems.

    A large portion of ME's security model is "security through obscurity", a practice that many researchers view as the worst type of security. If ME's secrets are compromised (and they will eventually be compromised by either researchers or malicious entities), then the entire ME security model will crumble, exposing every recent Intel system to the worst rootkits imaginable.

    Around 2013, we figured out some of the nitty-gritty details regarding how the ME firmware was packaged up into a blob. The ME firmware is verified by a secret boot ROM embedded in the chipset that first checks that the SHA256 checksum of the public key matches the one from the factory, and then verifies the RSA signature of the firmware payload by recalculating it and comparing to the stored signature. This means that there is no obvious way to bypass the signature checking, since the checking is done by code stored in a ROM buried in silicon, even though we have the public key and signature. However, there still might be an exploitable bug in the ROM bootloader.

    We also discovered that the critical parts of the ME firmware are stored in a non-standard compressed format, which gets decompressed by a special hardware decompressor. My initial attempts to brute-force the decompression scheme failed miserably. Another group had better success and they have now completed a working decompression routine for all versions of ME up to but not including version 11. Kudos to them!

    Our goal is to implement a completely libre software replacement for ME. When the implementation of such a security-critical component is available for scrutiny, it will be peer-reviewed and audited by persons around the world. This generally results in stronger security.

    Our goal isn't to replace Intel's ME, but to provide a minimal libre alternative firmware for users who choose to use it. Unfortunately, since the firmware is protected by RSA 2048, we currently have no way to execute our own code on the ME hardware because it fails validation. We have no way to move forward, even if we wanted to.

    This is scary. Most digital handcuffs are so easy to break that it's not an issue how to break it, more so an issue of the penalty one might face for actually breaking it. In this case, it is impossible to break unless you have a way to factorize semi-primes with approximately 600 decimal digits in a reasonable time. (At the time of writing this article, pretty much impossible in one human lifetime for anyone with the biggest supercomputer).

    So in conclusion, Intel has so far stopped anyone from tinkering with ME firmware in practice, and there is no way to trust the code running on your ME because it's proprietary. So we are back to the days of the Sony Playstation, but for general purpose computers based on Intel x86. Matters only get worse now that Intel has squeezed a whole system into a chip, SoCs. We have no physical separation between the components that we can trust and the untrusted ME components, so we can't even cut them off the mainboard anymore.

    Below is a highly simplified diagram describing how some of the older ME hardware fits into a system:

    Personally, I would like if my ME only did the most basic task it was designed for, set up the bus clocks, and then shut off. This way, it would never be able to talk out of the network card with some of my personal data. I refer to the ME as the Damagement Engine, since it is a hardware add-on that damages your security.

    (Banner: PIC12C508-HD, ZeptoBars, CC-BY; Diagram, CC0)

    / / 37 COMMENTS

    / / / / / / / / / / / /

    Notable Replies

    1. Sigh. When are we going to stop seeing this canard bandied about? Yes, I know, it's an article of some people's religious faith, but that doesn't make it true. Heartbleed, shellshock, freak... The list of security flaws in open source software that went unnoticed for years, even decades, is long and getting longer.

      Open source is no better than closed source at fixing security flaws. Arguably it is worse, to the extent that OSS is coded by volunteers, so there is nobody whose paycheck depends on finding and fixing flaws.

      Millions of eyes have no effect on the depth of bugs because finding security flaws is hard, un-fun work, and nearly all those eyes are volunteers doing things they enjoy... Which does not include auditing code for security holes. Only security researchers and hackers do that kind of thing for fun, and there aren't enough of them to audit all the code that needs auditing.

      Security through obscurity is stupid, and Intel should know better. But creating a FOSS alternative will not help. It will, rather, hurt, because then there will be two bundles of software (intels and the OS alternative) that need to be checked for security holes by the too small community of security researchers, instead of one.

    2. Not with the same enthusiasm as Intel: Server motherboards, pretty much regardless of vendor, will have an IPMI-or-more implementation of...widely varying...quaility; but "Intel AMT" is widespread across desktops and laptops(it's mostly a 'business' feature, so it's often gimped or disabled in consumer gear; but that still means that the capability is widely present in non-server chipsets.)

      This isn't so much a matter of virtue on AMD's part; but of tardiness: they've thrown in their lot with technology based on the 'TrustZone' stuff traditionally found in ARM cores; and are making a go of rolling out some similar capabilities. They just don't have much leverage in the business-boxes market.

      Speaking from my limited experience with Intel AMT(we don't use it at work; but some of the hardware we have is capable of it so we've tested it), one can see why it would be an attractive IT management feature; but one can also see why it would make people nervous.

      The capabilities depend both on firmware and on hardware(minor version bumps are usually doable with firmware; major version bumps occur when a new chipset is rolled out, wikipedia has a roundup of the versions).

      At least with reasonably new AMT, the capabilities are quite sophisticated. The ARC(or, amusingly enough, SPARC in newer versions; who would have thought that Intel is probably one of the world's leading SPARC vendors, by volume?) core remains active at all times when power is available(so all the time for desktops, most of the time for laptops) and has its own IP stack, so you can talk to it even if the main computer is powered off, has no OS, or even has all the RAM pulled. The AMT device can also(sometimes this requires cooperation with the guest OS, exactly when it does and doesn't gets really tedious really quickly) establish VPN links back to HQ even if the device is on an external network.

      One particularly impressive(if, equally, disconcerting) capability is the ability to act as an IP KVM: so long as the host computer is using intel graphics, you can connect through AMT and view the screen(including POST and boot stuff, prior to the OS loading) and use a virtual keyboard and mouse for remote control, as well as mounting ISOs over the network. It's based on a slightly oddball implementation of VNC; but it's a version of VNC that is baked into the hardware and works regardless of the state of the host OS.

      The capabilities are pretty cute; but, as always, 'pretty useful for the IT guys' and 'zOMG rootkit from hell!' is less a technical difference than a difference in ownership and motive.

    3. So this gives anything running this a remote lights out connection like all the HP servers have? Well provided the device has power and network.
      While I really enjoy this for servers (that are already behind firewalls and such, you aren't putting your prod servers directly on the net are you?) cause I don't have to do things like fly to Australia just to load the OS. This gives me concerns about workstations and laptops as an attack vector.

    4. That is literally apples and oranges.

      "Open Source" and "volunteers" have no fundamental connection between them.

      Or are you telling us that projects like NodeJS or Microsoft's .NET are being maintained by volunteers?

    Continue the discussion bbs.boingboing.net

    32 more replies

    Participants