Alternately, a simple XOR with a magic number means a set-to-zero
would un-XOR to a horribly wrong new "size". Even a fixed magic
number would increase hackability significantly, although a
per-process one would be better (and more expensive to do at runtime,
unfortunately).
See my old heap protector patches. You could probably swap in bswap
in place of the encryption, and it will just work.
Where do I find those patches?
Heck, even ~size would be interesting to ponder. The question is,
which operations will break-in attempts have access to?
Most overflows are more than just a single NUL byte, unfortunately.
This will, of course, further break dumped heaps, like emacs, but
hopefully we're past that by now.
Actually, that's not a problem. I think my heap protector patch
simply rewrites the dumped chunk headers into the appropriate format.
I will likely be busy with ABI-impacting work for many months to come,
so I won't finish the heap protector patches anytime soon.
I would be interested to take a look at those heap protector patches!
This seems to be promising!
But as of now, regarding my proposed patch, it would prevent the
Poison-Null-Byte attack immediately and with no performance impact,
which seems like a good solution until the heap protector is ready.
Thanks,
Moritz