An apparent misunderstanding of documentation from Intel led major operating system and hypervisor developers to...
introduce a bug in their hardware debug implementations, leaving almost all major unpatched operating system and hypervisor implementations on Intel and AMD systems open to a litany of attacks.
The vulnerability note issued by the CERT division of Carnegie Mellon University's Software Engineering Institute blamed the vulnerability on developers having misinterpreted the behavior of the hardware.
"In some circumstances, some operating systems or hypervisors may not expect or properly handle an Intel architecture hardware debug exception," the CERT advisory stated. "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."
How the hardware debug bug works
Nick Peterson of Everdox Tech LLC discovered the vulnerability, according to the CERT advisory, and worked with Nemanja Mulasmajic of Triplefault.io to turn the vulnerability into a local privilege escalation exploit. The two wrote a white paper describing the vulnerability, which relates to the way OS developers implemented hardware debugging commands for Intel x86-64 architectures; the vulnerability could allow an attacker to gain unauthorized access to kernel memory by submitting the proper sequence of commands -- either through malicious software or a user logged into the system.
The CERT advisory explained that "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. This may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions."
CERT also said that vendor interpretations of "potentially unclear existing documentation and guidance" for these instructions led to the collective misinterpretation by so many vendors.
OS vendors already patched the flaw
Major operating systems vendors have already issued patches for the flaw, which Microsoft assessed as unlikely to be exploited. In addition to Windows, other operating systems that have already been patched include macOS from Apple, Linux and FreeBSD; virtualization software was also affected, and both Citrix XenServer and VMware have also been patched. Open source OSes NetBSD and OpenBSD were both reported to be free of the vulnerability, while patches were provided for the Linux kernel, as well as for Linux distributions, including those from Ubuntu, Red Hat Inc. and SUSE Linux.
A Microsoft spokesperson told SearchSecurity that "Microsoft released security updates in May to address this, and customers who have automatic updates enabled or who have applied the updates are protected."
Microsoft's security update explained that the hardware debug bug creates an elevation of privilege vulnerability when the Windows kernel doesn't correctly handle objects in memory. "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights." However, to successfully exploit the vulnerability, "an attacker would first have to log on to the system. An attacker could then run a specially crafted application to take control of an affected system."
Microsoft issued patches for Windows 10, Windows 8.1, Windows 7 and Windows Server 2008, 2012 and 2016 on Patch Tuesday this month.
Apple had not responded to request for comment but posted a security update stating that for unpatched systems a malicious application that exploited the vulnerability would be able to "execute arbitrary code with kernel privileges," adding 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."