> On Thu, Sep 08, 2016 at 07:47:58PM -0400, Daniel Micay wrote: > > > A nice security property of 0xdf filling is that a use-after-free of a > > pointer is guaranteed to fault in a typical environment since it ends up > > pointing outside userspace (I assume that's the case on OpenBSD). A heap > > spray could potentially allow exploiting a random pointer. Perhaps it > > would be better if only the byte range guaranteeing faults for pointers > > was used? Less random, but strictly better than the current situation > > rather than losing a nice guarantee. > > AFAIK 0xdf...df it is not guaranteed, just often outside the address > space. > > I selected 0xdf a long time ago as an alternative to the 0xd0 (Duh) > byte used for new chunks. Both as a mnemonic for "free" and because it > is likely to cause segfaults. A pointer ending in 0xdf often will be > unaligned. Of course that won't work on all archs or all pointers. > > Random patterns are also likely to produce segfaults, using them as a > pointer has a big chance of being unaligned or pointing to an unmapped > page.
There is only one benefit from full-random. That it creates a little bit more register damage as the code goes fully astray. On non-shared address spaces, no byte-repeat address we choose is gauranteed to be outside the address space. Some of our architectures in that family do have full address spaces. On any such systems if the attacked can place something at that address before things go wrong, then he probably has substantial control already. A machine-dependent value could be chosen to land within the VA hole that some 64-bit architectures have, but shrug, I don't see the point. I think 0xdf is still the best of all worlds.
