CVE-2024-1086—a.k.a. Dirty Pagedirectory—is back in the news again and is an excellent demonstration of the limits of OS hardening and other “self-protection” mechanisms. It illustrates why modern runtime security can best be achieved by decoupling the method of protection from the object of protection. BlueRock achieves this separation with its groundbreaking workload protection platform. By managing the security-critical functions of the underlying hardware and providing a user-space Virtual Machine Monitor (VMM), BlueRock can perform out-of-band hardening, implement invisible instrumentation, and support non bypassable monitoring. Because these capabilities exist outside of the protected workload—rather than depending on the capabilities and integrity of the host OS—an adversary cannot bypass them even if they’ve achieved root or kernel privilege inside that workload. This approach makes BlueRock ideally suited to protecting modern workloads from the litany of exploits that leverage the types of primitives that enable techniques like Dirty Pagedirectory.
Even heavily hardened kernels are vulnerable
Although much was made of the fact the exploit worked successfully on a wide range of kernel versions used by popular distros without needing to be (re)compiled, the supreme irony of the Proof-of-Concept (PoC) for CVE-2024-1086 is that it also worked against Linux kernels that aren’t intended for production use: Google’s kernelCTF (both the LTS and the Mitigation instances). This is significant because the kernels are recent (6.x) and they include additional hardening and mitigations that may not be present in many mainstream distributions. These kernels represent bleeding-edge efforts to thwart attackers by one of the most technically sophisticated and well-resourced organizations in the world and they are still vulnerable.
The patch gap strikes again
Unfortunately, the ability to bypass advanced kernel mitigations is no longer academic. As CrowdStrike has reported and CISA has confirmed, exploitation of CVE-2024-1086 has been detected in the wild so—even though the patch has been “available” since late January—adversaries have been able to find and compromise vulnerable systems. The fact that attacks are becoming known so long after a fix became available shouldn’t surprise anyone but it should serve as yet another reminder of how ineffective existing approaches to exposure management can be.
Self-protection: necessary but not sufficient
Dirty Pagedirectory is a descendent of Dirty Pagetable which is, itself, a variation on the Kernel Space Mirroring Attack (KSMA). This progression of exploit techniques was accompanied by a progression of mitigations intended to address them, none of which has fully succeeded or—as we now see—proven to be especially durable over time.
Additional kernel instrumentation has become one of the main ways to attempt to improve protection. Tools like Linux auditd and eBPF-based solutions were supposed to help shine a light on malicious activities happening in a system. The drawback of such self-protection mechanisms is that they depend on the integrity of the very system whose integrity they are trying to protect or—to put it slightly differently—in order to make assertions about the state of the system they are protecting, these tools must start by assuming the system is in a “good” state. These tools can also adversely affect system performance, be trivially bypassed, or both. While these tools can provide valuable telemetry, that cannot be exclusively relied upon to provide the level protection that organizations require for their most sensitive workloads. Even when these tools are successful in identifying an attack, it is an attack that is already in progress (as opposed to a notification that an attack was prevented).
Virtualization-assisted protection: a better approach
Virtualization began as an attempt to use compute resources more efficiently, while maintaining separation of workloads in order to prevent them from interfering with one another. Over time, virtualization came to play a more significant role in security despite the fact that existing solutions had been optimized primarily to address operational concerns (rather than security). These virtualization platforms—like any other software—also created their own attack surface and were subject to their own vulnerabilities.
By contrast, BlueRock was built for security. It eliminates the shared attack surface between itself and the workloads it hosts, while maintaining the critical visibility and control necessary to prevent exploitation and maintain runtime integrity. It provides a capabilities-based security model that implements most functionality in unprivileged user-mode components with a small, modular codebase and well-defined interfaces that make it possible to formally verify its operation. It is also designed to leverage the built-in security capabilities of modern computing platforms. BlueRock combines all of these elements to create a strong, vulnerability-agnostic foundation that protects organizations’ most critical workloads from the sophisticated exploits in use today (like Dirty Pagedirectory), as well as those that may be used in the future.
Organizations looking for protection during the patch gap or a better way to harden their runtime stack should reach out to us for details on how BlueRock can help.
