[PATCH] malloc/malloc.c: Mitigate null-byte overflow attacks
Moritz Eckert
m.eckert@cs.ucsb.edu
Fri Nov 3 21:55:00 GMT 2017
>> 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
More information about the Libc-alpha
mailing list