TL;DR Domas' "Memory Sinkhole" is a clever attack, but in today's OS landscape, can be mitigated via a small software update.

Yesterday at Black Hat USA, I watched as Christopher Domas shed some light on a very exciting/terrifying vulnerability. He discovered that SMRAM accesses can be duped to read/write from the LAPIC instead of main memory, bypassing a host of protections enforced by the memory controller hub (MCH). From there he was able to exploit the Intel default SMI handler (which is typically copy/pasted by OEMs and other BIOS/UEFI vendors) even though there were no vulnerabilities in the software by creating what he named a "memory sinkhole", a region of memory that writes are discarded and reads all return 0. With this sinkhole, and some very clever memory management from the OS driver he wrote (operating in ring 0), he was able to install a root-kit into SMM (ring -2).

While this was a brilliant attack, and one that I love, having done some similar work with architectural vulnerabilities back in 2010, the sky is not falling. Intel independently discovered this weakness where legacy support violated security guarantees and has fixed it starting with the Sandy Bridge (released 2011) micro-architecture. For older CPUs there is an easy to deploy and software-based mitigation that Chris seemed to miss: VMM-enforced prevention of APIC relocation to the SMRAM region.

It is exceedingly common these days for even consumer systems and OSes to bundle a hypervisor (also known as a VMM) that silently runs from early boot-time (preventing ring -1 attacks such as Blue Pill) and optionally verified by UEFI SecureBoot. This is evidenced by the pass-the-hash protections in Windows 10, the kvm hypervisor being included in the Linux kernel mainline and Windows 8 having a VMM built-in on many versions. With the common availability of VMMs on systems, it is not too far a stretch to imagine a patch for this vulnerability provided as a software update to the hypervisor.

As a VMM researcher, I worked on a fork of the vmcpu thin-VMM for Windows, and used the VMM privileges (ring -1) to observe and modify a number of architectural events. Hypervisors can create a list of events that should trap to the VMM for analysis, one of the common events is a write to a model-specific register (MSR). In this VMExit handler, a one-line check can be added to VMM to prevent the LAPIC memory-mapped IO (MMIO) space from being remapped. If the MSR being written to is 0x1B, it can be silently discarded, such as this check in the vmcpu code. Without the ability to remap the LAPIC MMIO region, the attack is mitigated. If the remapping is needed for legacy support, the SMRAM memory address can be read from the MCH registers, and modifications to the MSR allowed as long as the LAPIC MMIO space does not overlap with SMRAM.

In conclusion, Christopher Domas discovered how an unrelated feature of the CPU used in a clever way could bypass a number of security protections. However, there is a software mitigation for modern systems. When this attack is compared to the work done by Corey Kallenberg et al., which required a firmware update to fix, Domas' attack is unique in that it exploits non-vulnerable software through architectural flaws, but the road to recovery is far more painful for Kallenberg et al.'s.