Multiple major operating systems and hypervisors contain a serious CPU chipset bug that could allow authenticated attackers to elevate privileges, read sensitive data in memory, control certain low-level functions, or cause a denial of service condition, prompting developers to issue security updates patching this flaw.
A vulnerability advisory issued on Tuesday by the CERT/CC at Carnegie Mellon University's Software Engineering Institute explains that the bug -- designated CVE-2018-8897 -- stems from a misinterpretation of instructions for how to properly handle an Intel architecture hardware debug exception.
Systems using x86 Intel or AMD chipsets are reportedly impacted by the vulnerability. As of May 1, 11 developers whose security was confirmed affected have issued a patch: Apple, Microsoft, DragonFly BSD Project, FreeBSD Project, Linux Kernel, Red Hat, SUSE Linux, Synology, Ubuntu, VMware and Xen.
Causing the confusion are the instructions "MOV SS" and "POP SS," which, according to the CERT/CC, "inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction... ." In other words, they are designed to delay certain debugging exceptions until a subsequent instruction has first been executed.
A May 8 security advisory from The FreeBSD Project provides perhaps the clearest explanation of how this can go wrong: "If that [subsequent] instruction is a system call or similar instruction that transfers control to the operating system, the debug exception will be handled in the kernel context instead of the user context," it states -- which means attackers who exploit this flaw can gain kernel access and cause mischief.
Discovery of the vulnerability is credited to researchers Nick Peterson of Everdox Tech and Nemanja Mulasmajic of Triplefault, who have presented their findings in a highly technical online paper. The paper summarizes the bug in more byzantine fashion, as follows:
- "When the instruction POP SS is executed with debug registers set for break on access to that stack location and the following instruction is an INT N, a pending #DB will be fired after entering the interrupt gate, as it would on most successful branch instructions. Other than a non-maskable interrupt or perhaps a machine check exception, operating system developers are assuming an uninterruptible state granted from interrupt gate semantics. This can cause OS supervisor software built with these implications in mind to erroneously use state information chosen by unprivileged software. On AMD hardware, not only is INT N affected, but so is SYSCALL. This means the INT 01 handler can be entered on a user stack pointer, since OS software has little to no reason to setup an IST or task gate for the INT 01 handler."
An advisory from Microsoft refers to the issue as an elevation of privilege vulnerability that exists when the Windows kernel "fails to properly handle objects in memory." Although it states that exploitation is unlikely, the company warns that attackers could leverage this bug to run arbitrary code in kernel mode, allowing them to "install programs; view, change, or delete data; or create new accounts with full user rights."
Apple also addresses the issue in a security update, noting that "in some circumstances, some operating systems may not expect or properly handle an Intel architecture debug exception after certain instructions. The issue appears to be from an undocumented side effect of the instructions. An attacker might utilize this exception handling to gain access to Ring 0 and access sensitive memory or control operating system processes."
Advisories were also issued by Red Hat, Synology, Ubuntu [1, 2], VMware and Xen.
