Hardening the Linux Kernel Slab Allocator

Description

The Linux Kernel SLUB implementation lacks heap object metadata isolation due to its obsessive aim at cache line usage and memory space optimizations. Consequently, SLUB architects have designed SLUB to reuse the data segment of an allocated object to store freelist information when the object is freed. Hence, attacks against heap metadata, such as Object-Out-of-Bounds, Use-After-Free, Double Free and Invalid Free can easily emerge in the presence of an object mismanagement. The objective of this work is to design a hardened allocator strategy that isolates the freepointer of each freed object, such that the aforementioned complications are mitigated even in the presence of a critical Kernel subsystem or driver vulnerability. Our approach leverages Intel’s Virtualization extensions and Xen’s altp2m subsystem to orchestrate an in-place freepointer isolation mechanism that stores and retrieves the freepointer of an object in segregated physical pages which are protected under the default memory view. The freepointer access is performed by dynamically switching to a carefully configured memory view which relaxes the permissions of the isolated metadata pages. In addition, an isolated physical memory page is arranged to host freepointers belonging to objects from different slabs, therefore, utilizing the full capacity of the physical frame. Our approach requires minimal adjustments in the base implementation of SLUB, as we mostly re-organize the allocator at the physical address space layer, while in the virtual address space we only modify the location of the freepointer within its objects. Our allocator induces a negligible memory overhead of only 5% on commodity Linux sessions with high loads of object caches and slabs. The low indicator is obtained thanks to the complete utilization of the shared isolated physical pages that occupy all their memory words with freepointers originating from various equally-sized slabs. Moreover, the performance assessment of our allocator yields encouraging execution latencies in most of the tested cases, with only a few exceptions that do not mirror real- world scenarios. In addition, according to our performance evaluation, the allocator proves scalability to multi-processing systems as it does not increase its runtime latency when more CPUs are enabled on the host machine.