Multiple operating system vendors issued coordinated patches this week to address a common vulnerability across their platforms, which was introduced thanks to widespread misinterpretation of Intel developer documentation.
According to the CERT/CC team, most major players (including Apple, FreeBSD, Microsoft, Red Hat, Ubuntu, VMWare and Xen, plus distros based on the Linux Kernel OS) built an uncannily similar privilege escalation flaw into their Intel-based products.
The flaw isn’t remotely exploitable – a bad actor would need to gain local access to the victim’s machine via malware or stolen credentials. But once in, CERT/CC explained that an attacker armed with OS APIs could access sensitive memory information, and also “control low-level OS functions” by gaining elevated access privileges to the kernel level – i.e., hijack the code that controls the PC, Mac or VM.
From there, Microsoft explained, it’s possible to install programs and malware; view, change or delete data; or create new accounts with full user rights.
On the more innocuous end of the threat-level spectrum, the issue can also simply crash the kernel by confusing the system, causing a denial-of-service state.
On the more technical front, the flaw (CVE-2018-8897) resides in a debug exception in the x86-64 architectures. To be clear, the issue doesn’t exist in the chip itself, but rather in the way developers have built their software stacks to interact with the processor.
As Red Hat explained, modern processors provide debugging infrastructure, used by system designers and application developers to debug their software and monitor events, including memory access (read or write), instruction execution and I/O port access.
“When such an event occurs during program execution, the processor raises a Debug Exception (#DB) to transfer execution control to debugging software,” the company said in its overview of the flaw. “This catches the debug exception and allows a developer to examine program execution state.”
Developers appear to have widely misunderstood the way Intel processors handle that exception, leading to the same issue popping up across the computing landscape.
“The error appears to be due to developer interpretation of existing documentation for certain Intel architecture interrupt/exception instructions, namely MOV to SS and POP to SS,” CERT/CC said.
The CERT/CC team explained the problem in an advisory: “In certain circumstances, after the use of certain Intel x86-64 architecture instructions, a debug exception pointing to data in a lower ring (for most operating systems, the kernel Ring 0 level) is made available to operating system components running in Ring 3.”
Nick Peterson of Everdox Tech, who first uncovered the vulnerability, pointed the finger at what he said was Intel’s lack of clarity in its instruction manual. In a technical brief, he noted, “This is a serious security vulnerability and oversight made by operating system vendors due to unclear and perhaps even incomplete documentation.”
We reached out to Intel and received an official statement:
“The security of our customers and partners is important to us. To help ensure clear communication with the developer community, we are updating our Software Developers Manual (SDM) with clarifying language on the secure use of the POP/MOV-SS instructions. We recommend that system software vendors evaluate their software to confirm their products handle the situations in question. More information is available here.”
Creating secure computing environments obviously takes coordination between the chipmaker, software developers and vendors; however, there are always blind spots. In this case, once the chip is out the door, Intel naturally has no visibility or control over how developers build software to use its silicon.
Speaking on background, an Intel spokesperson explained to Threatpost that because of this, becoming aware that a set of documentation is confusing or hard to read is something that can only be discovered over time, as products come out and security researchers test the OS stacks. Thus, it’s up to security development life cycle best practices to surface any issues, as it did in this case.
Source: ThreatPost
