What issues can arise from hardware debug exception flaws?

CERT issued an advisory regarding a problem with Intel's documentation, which inadvertently caused OS and hypervisor developers to create a hardware debug exception vulnerability in their software. What is the underlying hardware debug exception and what problems does it cause?

There are plenty of cases in which security vulnerabilities have been introduced into software programs because developers failed to correctly implement a third-party library or component, often due to a failure to read the relevant vendor documentation.

Vulnerability CVE-2018-8897 is somewhat different though, as the entire community of operating system and hypervisor developers appears to have misinterpreted a statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual.

This has resulted in a hardware debug exception vulnerability being introduced into developers' software, enabling an attacker to gain unauthorized access to kernel memory by submitting a specially crafted sequence of commands, either using malicious software or a user logged into the system. An attacker who successfully exploits this vulnerability could run arbitrary code in kernel mode, enabling them to install programs; view, change or delete data; and create an account with full admin rights.

Nick Peterson of Everdox Tech, along with Nemanja Mulasmajic of Triplefault.io, discovered the vulnerability and turned it into a local privilege escalation exploit. The vulnerability arose because of the way OS developers implemented hardware debugging commands for Intel x86-64 architectures. When Intel released its 8086 16-bit microprocessor chip in 1978, it added a special caveat for loading two stack segment (SS) registers: MOV SS and POP SS.

The SS register is usually used to store information about the memory segment that stores the call stack of the program that is being executed.

"Even though system software developers could add interrupt guards to code loading SS, Intel added functionality where loading SS with either of the two previously mentioned instructions would force the processor to disable external interrupts, non-maskable interrupts (NMI) and pending debug exceptions until the boundary of the instruction following the SS load was reached," Peterson said.

The purpose of this change was to prevent an interrupt from being recognized and used immediately after loading SS, but before loading a stack pointer -- a useful precaution based on the design of operating systems at the time -- but Peterson discovered an undocumented side effect of these changes.

After this functionality was added, system software developers assumed that when interrupts are disabled, debug exceptions are also disabled. However, a pending debug exception, NMI or machine check can still occur.

The occurrence of a debug exception executing before the interrupt handler can set up a good state, though that is admittedly an edge case, and can be used to trick the system into employing a user GS-BASE value. This may enable an attacker to utilize operating system APIs to gain access to sensitive memory information or to control low-level operating system functions.

All the main operating system and virtualization software vendors have already issued patches for the hardware debug exception flaw, which Microsoft assessed as unlikely to be exploited. However, it does show that not only do developers need to carefully read implementation documentation, but vendors also need to ensure that their documentation and guidance is complete, clear, easily understood and not open to misinterpretation.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)