MarkUs: Drop-in use-after-free prevention for low-level languages

Abstract

Use-after-free vulnerabilities have plagued software written in low-level languages, such as C and C++, becoming one of the most frequent classes of exploited software bugs. Attackers identify code paths where data is manually freed by the programmer, but later incorrectly reused, and take advantage by reallocating the data to themselves. They then alter the data behind the program's back, using the erroneous reuse to gain control of the application and, potentially, the system. While a variety of techniques have been developed to deal with these vulnerabilities, they often have unacceptably high performance or memory overheads, especially in the worst case.We have designed MarkUs, a memory allocator that prevents this form of attack at low overhead, sufficient for deployment in real software, even under allocation-and memory-intensive scenarios. We prevent use-after-free attacks by quarantining data freed by the programmer and forbidding its reallocation until we are sure that there are no dangling pointers targeting it. To identify these we traverse live-objects accessible from registers and memory, marking those we encounter, to check whether quarantined data is accessible from any currently allocated location. Unlike garbage collection, which is unsafe in C and C++, MarkUs ensures safety by only freeing data that is both quarantined by the programmer and has no identifiable dangling pointers. The information provided by the programmer's allocations and frees further allows us to optimise the process by freeing physical addresses early for large objects, specialising analysis for small objects, and only performing marking when sufficient data is in quarantine. Using MarkUs, we reduce the overheads of temporal safety in low-level languages to 1.1× on average for SPEC CPU2006, with a maximum slowdown of only 2×, vastly improving upon the state-of-the-art.

Automated Use-After-Free Detection and Exploit Mitigation: How Far Have We Gone?

“…Other static detectors and dynamic detectors are not considered because their prototypes are either unavailable or unable to run. To answer RQ5 and RQ6, we evaluate five publicly-available exploit mitigation tools: MarkUs [1], SlimGuard [41], Guarder [40],…”

“…Worst of all, some dangling pointers may survive for a long time, which further increases the memory overhead of garbage collection. Another key limitation is that they may free objects that are still referenced by hidden pointers [1], thus causing UAFs themselves.…”

“…Delay memory reuse. Many mitigation techniques delay memory reuse until a criterion is met [1], [16], [18], [44], [63], [87], [91], [124], [130]. For example, MemGC [124] delays memory reuse until the total size of unreferenced chunks reaches a dynamically calculated threshold (that is, criterion).…”

“…The design limitation is that its protection is probabilistic. MarkUs [1] differs from other memory reuse-delay approaches in that it delays memory reuse until it cannot find dangling pointers to freed objects.…”

“…U Se-After-Free (UAF), that is, dangling pointer dereferences on the freed memory object, is top security vulnerability [1], [2]. Previous research shows that in the NVD database, 80.14% of UAFs from 2007 to 2016 are rated as critical or high severity [3], with an increasing number of UAFs every year.…”