MineSweeper: a “clean sweep” for drop-in use-after-free prevention

Abstract

Low-level languages, which require manual memory management from the programmer, remain in wide use for performance-critical applications. Memory-safety bugs are common, and now a major source of exploits. In particular, a use-after-free bug occurs when an object is erroneously deallocated, whilst pointers to it remain active in memory, and those (dangling) pointers are later used to access the object. An attacker can reallocate the memory area backing an erroneously freed object, then overwrite its contents, injecting carefully chosen data into the host program, thus altering its execution and achieving privilege escalation.We present MineSweeper, a system to mitigate use-after-free vulnerabilities by retaining freed allocations in a quarantine, until no pointers to them remain in program memory, thus preventing their reallocation until it is safe. MineSweeper performs efficient linear sweeps of memory to identify quarantined items that have no dangling pointers to them, and thus can be safely reallocated. This allows MineSweeper to be significantly more efficient than previous transitive marking procedure techniques.MineSweeper, attached to JeMalloc, improves security at an acceptable overhead in memory footprint (11.1% on average) and an execution-time cost of only 5.4% (geometric mean for SPEC CPU2006), with 9.6% additional threaded CPU usage. These figures considerably improve on the state-of-the-art for non-probabilistic drop-in temporal-safety systems, and make MineSweeper the only such scheme suitable for deployment in real-world production environments. CCS CONCEPTS• Security and privacy → Software and application security; Systems security.

Efficient Use-After-Free Prevention with Opportunistic Page-Level Sweeping

“…We also assume that HUSHVAC is well-written and does not include any exploitable vulnerabilities. Note that this set of assumptions is consistent with prior work on use-after-free mitigation and prevention [11,17,18,36].…”

“…This design choice builds on three observations. Firstly, as per our experiments and prior work [18], promptly invoking unmap without batching does not significantly impact execution time, but helps in reducing memory usage. Secondly, invoking mmap in this manner does not fragment the kernel's VMA structure.…”

“…Recent studies [11,17,18,36] demonstrate that postponing the reuse of freed heap chunks can effectively reduce use-afterfree vulnerability exploits. They postpone the reuse until all dangling pointers have vanished or until the program terminates, ensuring that no dangling pointer remains associated with any allocated heap chunk.…”

“…Reusing Freed Chunks after Ensuring No Dangling Pointers. MarkUs and MineSweeper [11,18] take the former approach, allowing the allocator to reuse a freed chunk only after a memory scan confirms the absence of dangling pointers. They begin by differing the frees by placing the freed chunks on the quarantine list.…”

“…Delaying the reuse of the freed memory chunks until the pointers to them disappear from memory is a promising approach to preventing use-after-free vulnerabilities. Markus and MineSweeper [11,18] are state-of-the-arts in this direction, and with relatively low overhead in several benchmarks. When compared to the others, they exhibit relatively low overhead on execution time and do not require special hardware features that are not accessible on commodity processors, while deterministically preventing temporal safety violations unless the program hides the pointers.…”