[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