Negative Rings in Intel Architecture: The Security Threats That You’ve Probably Never Heard Of

Not Actual Protection Rings, But Conceptual Privilege Levels Susceptible To Exploitation

Most likely, you’re aware of the hardware “protection rings” in Intel Architecture processors — the familiar “Ring 0” for the kernel through “Ring 3” for userland. But, have you ever heard of “rings” “minus one” through “minus three”? If not, you’re missing out on three entire levels of processor vulnerabilities.

Ring 0 Through Ring 3

In Intel Architecture (IA) processors, there are four protection rings, which are implemented in hardware using two bits in the Segment Descriptor Table, called the Descriptor Privilege Level (DPL) bits. The hardware logic behind the rings allows processes running at a given privilege level to access memory at that privilege level (ring number) or higher. Thus, anything running in Ring 0 (DPL of 0) can access anything in any of the other positively-numbered rings. Likewise, anything running in Ring 3 (DPL of 3) can only access other Ring 3 memory. [See notes 1 and 2.]

In normal usage, the rings are allocated as follows:

• Ring 0: Kernel (Highest Privilege)
• Ring 1: Device Drivers
• Ring 2: Device Drivers
• Ring 3: User Applications (Lowest Privilege)

This concept is illustrated in the “Standard IA Protection Rings” drawing, below. The way to view these rings is that you can only access outward, to a higher-numbered ring. That is, you can never access inward, to a lower-numbered ring.

Standard Intel Architecture Protection Rings

There are some variations to how the rings are used, but the access limitations remain the same. For example, in many cloud environments, the hypervisor sits in Ring 0, a user’s kernel is in Ring 1, that user’s device drivers are in Ring 2, and that user’s Applications are in Ring 3. This concept is illustrated in the “Alternate (Cloud) IA Protection Rings” drawing, below.

Alternate (Cloud) Intel Architecture Protection Rings

Let’s Get Negative!

On Intel Architecture chipsets, there are three more levels of privilege, all with a higher-level privilege than the operating system’s kernel. We call those “Ring ‑1” through “Ring ‑3,” with Ring ‑1 (pronounced, “ring minus one”) being the least privileged of the negative rings, and Ring ‑3 being the most privileged. Thus, Ring ‑3 can access anything in Ring ‑3 through Ring 3. And Ring ‑2 can access anything in Ring ‑2 through Ring 3, but it cannot access Ring ‑3.

Now, allow me to emphasize a point: Negative rings are conceptual levels of privilege, not actual processor protection rings.

Unlike the “positive rings,” which are implemented in hardware with a pair of bits to specify the Ring number, no equivalent set of bits exist to specify negative ring numbers. There are bits that specify state for Rings ‑1 and ‑2; and, Ring ‑3 is actually a separate processor within the processor chipset. We will briefly discuss how the processor knows it is running a process in a negative ring when we cover that ring.

Each of the negatively numbered rings is reserved for a specific use. That assignment is as follows:

• Ring ‑1: Hypervisor
• Ring ‑2: System Management Mode (SMM)
• Ring ‑3: Management Engine (ME)

This concept is illustrated in the IA Negative Rings drawing. Again, the way to view these rings is that you can only access outward, to a higher-numbered ring. That is, you can never access inward, to a lower-numbered ring.

Intel Architecture Negative Rings

Thus, the complete view of the ring architecture becomes:

• Ring ‑3: Management Engine (ME) {Highest Privilege}
• Ring ‑2: System Management Mode (SMM)
• Ring ‑1: Hypervisor
• Ring 0: Kernel
• Ring 1: Device Drivers
• Ring 2: Device Drivers
• Ring 3: User Applications {Lowest Privilege}

Now, let’s take a look at each of the negative rings in more detail.

Ring ‑1: Hypervisor

First, we need to clarify what type of hypervisor we are discussing. There are two widely-recognized types of hypervisors:

• Type 1 Hypervisors, which run on “bare metal.”
• Type 2 Hypervisors, which are “hosted.”

A type 1 hypervisor has actual control of the computer. It is what boots upon startup. Examples of type 1 hypervisors include: VMware ESXi, Microsoft Hyper-V, and Linux KVM.

A type 2 hypervisor runs as an application under the computer’s operating system. Examples of type 2 hypervisors include: VMware Workstation and Fusion, Microsoft Virtual PC, and Oracle VM VirtualBox.

For purposes of the following discussion, “hypervisor” always refers to Type 1 Hypervisors, unless explicitly stated otherwise.

Virtualization must be enabled via a firmware setting to enable the bare metal boot of a hypervisor. When virtualization is set, that enables the Virtual Machine eXtensions (VMX) in the Intel processor. Whenever VMX is enabled, the processor runs in one of two modes:

• VMX Root, or
• VMX non-Root.

VMX Root is the mode in which the hypervisor runs. In VMX Root, the hypervisor has access to special virtualization instructions unavailable to any other processes. The hypervisor runs with DPL set to 0. But, the hypervisor (running in VMX Root mode) is isolated from the virtualized guest operating system whose kernel runs in VMX non-Root mode, with its virtual DPL also set to 0.

Thus the boot process becomes:

• Firmware enables VMX.
• Firmware boots the hypervisor and passes control to it. It runs in VMX Root DPL 0.
• Hypervisor then boots each guest operating system kernel. Each guest runs in VMX non-Root, with each operating system’s kernel running in their own virtualized DPL 0.
• Each guest operating system then performs its normal startup procedures.

Again, this is a vastly oversimplified summary of what occurs when running a bare-metal hypervisor. I do need to add one point of clarity: When a virtualized process runs, it runs with the processor’s actual protection level set to its virtualized DPL. That is, both the hypervisor and each guest operating system kernel are going to run in Ring 0. However, the processor’s virtualization technology prevents a guest operating system from accessing either the hypervisor’s memory space or the memory space of another guest operating system.

To clarify that the hypervisor is more privileged than the guest operating systems (which run with a VMX non-Root DPL 0), the hypervisor’s VMX Root protection level is referred to as “Ring ‑1” (which is, in reality, VMX Root DPL 0).

Confused? Yeah, I know it’s confusing. But, you don’t have to understand all these gory details to grok that the hypervisor is running at a level more privileged than the guest operating systems’ kernel (Ring 0), and that privilege level is referred to as Ring ‑1.

Ring ‑2: System Management Mode (SMM)

To understand SMM, the first concept that’s needed is that of processor modes. [3]

When the processor comes out of reset (such as after power-on or reboot), the processor is in “Real Address Mode” (usually called “real mode”). In real mode, all memory addresses are real addresses (no virtual memory), there is no memory protection, and the processor instruction set is limited.

While in real mode, the processor’s firmware (BIOS, UEFI, etc.) performs several initialization tasks, including installing the system management software into memory. It then loads special processor registers with the memory address range occupied by the system management software and its software interrupt table. Once this initialization of the system management software is completed, its memory space “disappears” from available memory.

Once the firmware has completed its initializations, it switches the processor into “Protected Mode,” which enables memory protection (“rings”), memory virtualization, and other hardware-level memory protection and management capabilities. (In 64-bit processors, there are additional modes added, but we will not cover them here.)

What is this “system management” software installed by the processor’s firmware? Typically, it is the OEM’s computer-specific software for power, thermal, and other hardware management. Sometimes vendor-specific security software is also installed as a system management component.

The system management software only executes when the processor is in “System Management Mode” (SMM). SMM is the highest priority processor state that exists. When entering SMM, all other processes on the system are suspended, and processor state is saved. The processes have no awareness they have been interrupted. Upon exiting SMM, processor state is restored, and processing resumes as though no interruption had occurred. SMM program execution is completely transparent to the entire rest of the processor.

There are three ways which SMM can be entered:

• Hardware triggered, via a System Management Interrupt (SMI). That is, there is a physical pin on the processor chip, which, when activated, causes the processor to enter SMM.
• Software triggered, via an interrupt triggered through the Advanced Programmable Interrupt Controller (APIC).
• Clock triggered, via a timer within the system management software. (This is actually a software triggered event. But, I mention it separately because I want to point out that the system management software itself can trigger its own execution.)

When in SMM, the system management software has total control of the processor. It can access all of memory and all of its peripherals. It can even access the hypervisor. Since it is more privileged than the hypervisor, we assign it the logical privilege level of “Ring ‑2.”

Ring ‑3: Management Engine (ME)

Never heard of the Intel Management Engine? You’re far from alone! [4]

The Management Engine (ME) currently resides in a chip called the Platform Controller Hub (PCH). It has its own separate processor. Over time, varying architectures have been used to implement the ME processor.

The ME is downright scary. It is always running, even when the system is powered off; as long as the mainboard has power (line power or battery), the ME is running. It has its own MAC and IP addresses, and full access to the main processor, all memory (including SMM) and all peripherals. It cannot be disabled, as the main processor cannot boot in the absence of a running ME.

Oh, and it even runs its own web server. If that alone doesn’t terrify you, it should.

And think about the fact it has its own MAC and IP addresses. That means that you can’t firewall off the ME in the host processor. The only way you can detect that the ME is communicating with the world is by monitoring all network traffic exiting that system.

The ME processor is “invisible” to the main processor. That means that you can’t protect it with any type of anti-malware software, or otherwise inspect the processor for potential compromise.

It has been discovered that there is an ME mode called “High Assurance Platform,” which was allegedly developed for the exclusive use by TLA government agencies to limit the ME’s capabilities after system boot. But, its use outside of that environment allegedly violates your warranty. [7]

What does the ME do? Its full functionality has never been publicly documented. Most of what is publicly known about it has been discovered by several groups who have attempted to reverse engineer its capabilities. It’s known that the ME implements secure and trusted (verified) boot, it manages the other PCH functions, provides DRM and TPM functionality, and is where the Intel Active Management Technology (AMT) is implemented.

There have been known exploitable vulnerabilities found in the ME, for which Intel has issued several firmware updates.

As it is more privileged than even SMM, it is generally referred to as “Ring ‑3.”

So, let’s review:

• You have a “hidden” processor on your computer.
• Its functionality has never been publicly documented.
• It appears to have been customized for certain TLA government agencies.
• It has unlimited access to the main processor.
• It has unlimited access to all memory.
• It has unlimited access to all peripherals.
• It has its own MAC and IP addresses.
• It runs a web server.
• It is always running.
• You can’t turn it off.
• You can’t disable it.
• It has had known exploitable vulnerabilities (which presumes more vulnerabilities exist that have yet to be found and/or disclosed).
• It is the single most privileged known element of an Intel Architecture processor chipset.

If you’re not scared yet, then you haven’t been paying attention! In that case, I suggest you read what the EFF has to say about the ME: Intel’s Management Engine is a security hazard, and users need a way to disable it.

What About Microcode?

By this time, you are probably wondering how microcode fits into this picture. I’m not going to go into any detail beyond showing where microcode fits into the picture.

In most processors today, the machine code instructions are hardwired into the circuitry for performance. However, some complex machine code instructions are not easily processed in circuitry, so they are broken up into small sequences of microcode. Think of it this way: Some machine language instructions are directly executed by processor circuitry, while other machine language instructions have to be broken into simpler instructions (microcode) in order to be executed by processor circuitry.

In the Intel Architecture, the microcode for a given processor is burned into an on-processor ROM. Microcode can be updated by specially prepared packages from Intel. However, those microcode updates do not modify the ROM. Rather, they are stored in on-processor high-speed SRAM. As SRAM is volatile, all microcode updates must be reapplied with every processor reboot.

It is not clear from Intel documentation whether the ME’s processor also receives microcode updates. (It does, however, definitely receive firmware updates.)

From a “Ring Perspective,” microcode sits directly on top of the processor’s silicon. Logically, it can be considered an integral part of the processor itself. This is illustrated in the “IA Hardware View” diagram, below.

Intel Architecture Hardware View

How microcode is updated is one of the best-guarded secrets in the industry. It is known that updates are encrypted and digitally-signed multiple times. I can find no evidence that the exact format of the update package has ever been successfully reverse engineered.

However, should anyone ever be able to tamper with a processor’s microcode, it would be “game over,” as such an attack would, in all probability, be undetectable. Thus, although I do not call it that, you could probably consider microcode to be “Ring ‑4.” Although, who knows? Intel may have other yet-to-be-discovered conceptual privilege levels between the ME and the microcode. (If you want to apply a “ring name” to it, perhaps microcode best be called “Ring ‑∞,” as I don’t think you can get more privileged than microcode!)

What Security Threats Do I Need To Worry About?

All three of the negative rings discussed in this article are subject to exploitation. However, some of these rings have more potential to be exploited than others. The only real way to discover the exploitation of any of these negative rings is to detect the network traffic generated when the exploit phones home.

Hypervisor

Hypervisor attacks are relatively old. The most famous of the early attacks is the Blue Pill attack on the AMD virtualization technology, which was later ported to also exploit Intel technology.

There are three basic types of attacks that exploit virtualization technologies: [5]

• Hypervisor Injection, where an operating system running on bare metal has a “hypervisor” (called a Virtual Machine Based Rootkit, or VMBR) inserted between it and the hardware. An alternative attack is to inject a virtual hypervisor between the hypervisor and a guest operating system, such as the cloudskulk attack.
• Hypervisor Escape, where an exploit run from a guest operating system gains access to either the hypervisor, to another guest operating system, or to the bare metal hardware.
• Side-Channel Attacks, where a guest operating system exploits processor hardware flaws, or other vulnerabilities, to extract information from another guest operating system executing on the same physical hardware. [6]

Hypervisor Injection attacks against bare-metal operating systems used to be relatively trivial to carry out. However, recent firmware and chipset hardening have made such exploitation more complicated than it has been in the past. A substantially greater risk is the cloudskulk-like attacks that inject a VMBR in an already virtualized environment. In today’s cloud computing environment, such attacks are a growing concern.

Hypervisor Escape attacks are our current greatest hypervisor risk. There have been literally dozens of recent vulnerabilities discovered which allow for attackers to escape from virtualized guest systems. A relatively complete list of known vulnerabilities and attacks can be found here.

Side-Channel Attacks are a rapidly growing threat. It seems as though every few weeks, a proof-of-concept is developed for some new side-channel attack. A good overview of the concepts behind side-channel attacks can be found here.

Most recent side-channel attacks have been exploiting one of the various Meltdown or Spectre vulnerabilities. The original research describing those vulnerabilities can be found here. A recent video tutorial on Meltdown and Spectre (based upon Dickens’ A Christmas Carol) can be found here (original) or here (YouTube); Warning: Some language may be NSFW.

Today, successful side-channel attacks are probably beyond the capabilities of all but state actors. But, it is only a matter of time before they become commodity point-shoot-kill exploits any criminal can purchase on the dark web.

All classes of hypervisor attacks are a critical problem in cloud computing. In fact, I contend that it is impossible to adequately secure any public cloud system processing sensitive information. I will delve into those details in an upcoming blog posting, Increasingly Cloudy with Severe Security Storms: Why It Is Impossible to Secure the Public Cloud.

Finally, don’t forget hypervisors are software. All software has bugs. You can’t assume that your hypervisor is not exploitable. Always ask the question: How can this software be used against me?

System Management Mode

To attack SMM, you need to attack the firmware. For that reason, SMM exploits are often called “BIOS Rootkits” or “Bootkits.” With recent lockdowns of the boot process, many attacks against firmware have become more difficult. However, on many systems, an attacker who can access the firmware configuration settings has the potential to disable those protections.

Today, most SMM exploits that are publicly known have been developed by either state actors or those companies who sell exploits to state actors. The presentation UEFI Firmware Rootkits: Myths and Reality — Black Hat Asia 2017 provides a good overview of some relatively recent SMM exploits. An example of a rather notorious bootkit is LoJax, which attacks UEFI.

My biggest SMM concern is OEM bootkits. Like all SMM malware, they would be virtually undetectable, except by monitoring network traffic. And, since the malware was installed by the vendor, no attack vector to gain access to modify the firmware is required.

There is one potential defense against non-OEM SMM exploitation that is usually quite effective. Most SMM exploits require that the firmware be reflashed to install the malware. Many desktop and server systems have a physical jumper on the mainboard where you can disable firmware flashing. Disabling it is a trade-off between security and convenience. So, ask yourself: How often do we reflash firmware? Then, decide appropriately.

Finally, don’t forget what runs in SMM is software. All software has bugs. You can’t assume that SMM is not exploitable. Always ask the question: How can this software be used against me? And, for SMM, you need to add the question: Do I know what software is running in SMM? (Answer: Probably not!)

Management Engine

Management Engine attacks concern me the most.

Thus far, there have been about a dozen patched and disclosed vulnerabilities in the ME. How many more there are which are known but not yet patched and/or disclosed is not known. A few notorious examples of ME vulnerabilities and exploits include:

• Data Stealing Malware Found Using Intel AMT Tool to Bypass Firewall
• Unauthenticated Users Can Remotely Access Intel ATM Web Interface
• Critical Information Disclosure Bug in Security Engine

I am going to spend a lot more time on the ME in upcoming blog posts. [8] Meanwhile, some of the best information on the ME can be found on the Positive Technologies website.

Just keep in mind that it only requires one bug in the ME for your computer to be hacked, even when it is powered off!

For anyone into bug-bounty hacking, both Intel’s Management Engine and AMD’s Platform Security Processor are probably gold mines, just waiting to be discovered.

Finally, don’t forget what runs in the ME is software. As experience has shown, the ME software has had bugs. You must assume that the ME is exploitable. Always ask the question: How can this software be used against me? And, for the ME, you need to add the question: Do I know what software is running in ME? (Answer: Definitely not!)

Detection

Detection! That’s the crux of the problem with negative ring attacks.

As I have indicated, attacks originating from negative rings are essentially undetectable from the positive-numbered rings. Yes, there are a few indirect ways you can possibly determine that you’ve been pwned, and even fewer direct ways. And, both direct and indirect methods only apply to certain small groups of exploits. Your safest bet is to assume that your anti-malware tools cannot detect any negative-ring attacks.

There is exactly one way which stands any chance of detecting that you’ve been compromised: network monitoring. That means you must be able to monitor all traffic exiting and entering any physical network interface on the system. The key words here are “all,” “any,” and “physical.” Physical means that monitoring virtual networks is insufficient, because the ME can leak information through your network, and no level of virtual network monitoring would detect it. Any and all means exactly that: All traffic through any network interface. To do otherwise, you will leave holes in your security large enough to navigate an aircraft carrier through, undetected.

Regardless of your environment, today, the only effective means of breach detection are network monitoring and physical security (where the physical security threat is the malicious insider).

Summary

What runs in each of the negative rings is software. You have to assume the negative ring’s software is buggy and exploitable. You have to monitor your network traffic to detect rogue packets from exploited software in negative rings.

There are three conceptual privilege levels which have greater privilege than the operating system’s kernel. Those levels are referred to as:

• Ring ‑1: Hypervisor
• Ring ‑2: System Management Mode
• Ring ‑3: Management Engine

Unlike the positive numbered protection rings, which are designated by hardware protection measures, the negative numbered rings do not indicate a protection level. Instead, they indicate a relative privilege level, where the lower (more negative) the number, the greater the privilege level.

Hypervisors are software that boots into a special hypervisor mode (VMX), which enables special instructions only usable by the hypervisor. The hypervisor co-resides in ring 0 with the guest kernels it manages. A hypervisor executes with a special protection level called VMX Root, which isolates it from other ring 0 processes. Guest operating systems execute with the protection level VMX non-Root, which isolates them from the hypervisor and other ring 0 processes.

System Management Mode software is loaded by the boot firmware, which locks it into memory inaccessible by a hypervisor or operating system. The memory in which it resides appears to “disappear” from available real memory. SMM can software executes in a special processor state which renders its execution invisible to all other software running on the processor.

The Management Engine runs on a separate processor on the PCH chip. It is always running even when the main processor is powered off. It has full access to all memory and peripherals, and it has its own MAC and IP addresses. Without a functional ME, the main processor cannot boot. It is invisible to the main processor, and its integrity must be trusted because it cannot be verified by the main processor or by other known means.

The SMM is probably the most difficult of these three subsystems to compromise, as it involves successfully tampering with the processor’s firmware.

The hypervisor is probably the easiest of these subsystems to compromise, as it would be rather trivial to inject a hypervisor exploit under an operating system. This attack vector works against both operating systems running on bare metal, and operating systems which run as guests of a legitimate hypervisor.

The ME appears to be potentially open to simplistic exploitation. Compromising it would definitely be the most deadly subsystem to exploit.

Finally, I once again need to repeat: The only way most organizations can detect the exploitation of any of the negative rings is through monitoring of network traffic to detect exfiltration from any of these negative rings.

It’s exploitation time! Do you know what’s running in your negative rings?

Notes

1. Nearly everything presented in this paper is a greatly oversimplified explanation. My objective is to introduce big-picture concepts, not nitty-gritty technical details. Thus, I hope these oversimplifications provide sufficient details of the concepts I present here.
2. The major takeaway for this paragraph should be: The numerically larger the Ring number, the lower the privilege level.
3. Reference: Intel® 64 and IA-32 Architectures Software Developer’s Manual
4. AMD has a similar processor called the AMD Platform Security Processor, which implements its AMD Secure Technology subsystem.
5. This section applies to both type 1 and type 2 hypervisors.
6. The primary difference between Hypervisor Escapes and Side Channel Attacks is that an escape executes code on its target, and the side channel “only” leaks data.
7. TLA: Three Letter Acronym (e.g., NSA, CIA, FBI, DOD, NRO, MI5, etc.).
8. The first of these posts is now online, Ever Heard of MINIX? It’s The World’s Most Widely Used Operating System.

Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.

About The Blogger

Featured Image

Intel Architecture Negative Rings