- Complete title: S2malloc: Statistically Secure Allocator for Use-After-Free Protection And More
- PDF: short paper, full paper
S2malloc consists of three new constructs in the secure alloca- tor design space: free block canaries (FBC) to detect UAF attempts, random in-block offset (RIO) to stop the attacker from accurately overwriting the victim object, and random bag layout (RBL) to impede attackers from estimating the block size based on its address.
- Free Block Canaries are simply canaries put in free'd blocks, and checked upon reallocation (9as well as the neighbouring ones), like hardened_malloc has been doing for ages. Nothing is said about giving memory back to the operating system, so odds are it doesn't happen?
- Random in-block offset is a simple random offset for each allocations, like musl's malloc-ng cycling offset (2020), but randomized instead of incremented.
- Random bag layout seems to be area subdivision to increase the chance of having objects of the same size in vastly different places, to "obfuscate the virtual memory allocation and stops linking block sizes to their addresses." This sounds useless at best: an attacker with a read primitive won't be hindered, and this is irrelevant for one without one.
The software artifact is open-sourced.
And yet the provided link results in a 404, but maybe it'll be published after DIMVA 2024, who knows.
There is a comparison table, but it only contains some old academic allocators: DieHarder from 2010, Guarder from 2018, SlimGuard from 2019, MarkUs from 2020, and FFmalloc from 2021; while calling them "state-of-the-art secure allocators." Amusingly, the paper mentions hardened_malloc and scudo, but doesn't do any benchmarking against them.
The paper uses some variables like "a canary of length c" or "we put a ι-byte canary immediately after the last
data-storage byte in the allocated slot (i.e., the (p + b − e)th byte)", but
never defines them.
S2malloc provides protection toward UAF-read based on the assumption that the attacker cannot distinguish the memory content stored in the victim data field from the content stored in other data fields.
This is a completely bonkers threat model. The exploits tested against S2malloc weren't apparently tailored against it, sigh.
Through various real-world CVEs and benchmarks, we show that S2malloc can successfully detect all attacks while incurring 2.8% CPU overhead and 27% memory overhead on the PARSEC benchmark and 11.5% CPU overhead and 37% memory overhead on the SPEC benchmark
Generally, S2malloc takes more time to execute malloc() than all other com- pared memory allocators, and takes less time to execute free() than DieHarder but longer time than Guarder and SlimGuard. However, a significant overhead comes with our cryptographically secure canary implementation, which should be a standard adopted by all memory allocators.
Those are comically large values, at best, especially in the paper's operating threat model.
However, in previous entropy-based allocators, this value is set to be either globally identical or bound with slots so that a knowledgeable attacker can trivially break. We follow the previous secure canary designs to use the secure MAC of the memory address as the canary. Specifically, we take the CMAC-AES-128 encrypted block address as the canary implemented using AES-NI (on x86) or Neon (on AARCH) to keep the canary confidential and compact.
However, a significant overhead comes with our cryptographically secure canary implementation, which should be a standard adopted by all memory allocators
This is a great way to tank performances for completely imaginary security gains, and to excuse it by saying that it's the other's allocators fault for not using it as well.
In addition, S2malloc is designed to monitor the integrity of the heap actively and watch for UAF attempts, including heap spraying practices that aim to prepare the heap data and layout for UAF exploits. S2malloc achieves this through a synergy of regular heap canaries(§4.4) and FBC (§4.5). Consequently, S2malloc provides a robust security guarantee and cannot be easily evaded.
Wtf does this even mean.
tl;dr Nothing really novel, useful, nor practical. The only positive point is that the paper used mimalloc-bench.