I made a video about how hardened malloc can help secure against very simple heap overflows. If you have time, I'd be happy if you could review the video and tell me where I made mistakes, and what more I can learn about libhardened_malloc.
Conversation
Replying to
One thing to note is that when canaries are enabled (which is the default), they add 8 bytes to the size of allocation requests, so some allocations are pushed into a higher size class, which needs to be taken into account when checking the table to determine the size class.
1
The offset test prints the measured offset between different size classes and has to take canaries into account: github.com/GrapheneOS/har. It's a useful way of demonstrating the isolated regions for each size class and randomization of the guard regions and slab slot selection.
1
To test the randomization, you can run the offset test multiple times and compare the results across runs. Also worth noting there's a `preload.sh` script to handle that for you when testing with dynamically linked executables not linked with libhardened_malloc.so.
1
Also, from the maps outside, either in gdb or /proc/PID/maps, you'll be able to see the randomly sized guard regions placed around large allocations, along with the guard slab feature. Both of these are enabled by default, and the default guard slab setting is very aggressive.
1
The guard slab feature literally just skips allocating certain slabs from the region. The default value is aggressive and skips every other slab, so every slab has a guard slab on both sides which remain as PROT_NONE mappings. In the future, there will be more slab randomization.
At the moment, the only randomization for slabs is the high entropy isolated base for each region along with random slot selection within slabs. Randomizing the location of guard slabs and selection of slabs themselves rather than just slots within is planned, just not high prio.