Title: Paper notes: S2malloc
Date: 2024-06-18 15:00

- Complete title: S2malloc: Statistically Secure Allocator for Use-After-Free Protection And More
- PDF: [short paper](https://cs.uwaterloo.ca/~m285xu/assets/publication/s2malloc-paper.pdf), [full paper](https://arxiv.org/pdf/2402.01894)

> 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](https://research.nccgroup.com/2024/06/11/pumping-iron-on-the-musl-heap-real-world-cve-2022-24834-exploitation-on-an-alpine-mallocng-heap/) (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](https://github.com/ssg-research/s2malloc) results in a 404,
but maybe it'll be published after [DIMVA 2024](https://dimva.org/dimva2024/),
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](https://github.com/GrapheneOS/hardened_malloc) and
[scudo](https://llvm.org/docs/ScudoHardenedAllocator.html), 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](https://github.com/daanx/mimalloc-bench/).