Hi all, for a university project, I have been working on a LD_PRELOAD wrapper for the string.h functions, similar in concept to HeapShield [1]. In short, I wrap all functions, determine the size of the usable allocation, then (if available) I translate the original call into a safer one (strcpy becomes strlcpy, and so on). I have been mostly targeting 6.x, where I wrote my own code to figure out the allocation size. On 7.x though, I figured I could use malloc_usable_size(). However, I encountered a few problems. First of all, jemalloc makes no effort (neither here nor in free(3)) to survive being called with non-malloc'ed pointers. If you do that and asserts are on, you will get an abort, but if they are not your process will likely die an horrible death--but there's no explicit guarantee of that. I suppose that's fine (we are talking major WTFs after all) in general, although it would be nice to have more control. phkmalloc had more limit checking, so bad pointers (text / stack) were reliably detected. Worse, malloc_usable_size() fails if you pass it a pointer inside a malloc'ed region. Again, you get an assert if that's enable, otherwise you probably get a random value. The reason for this is in arena_salloc, where the passed pointer is compared to the calculated page, to determine whether we are dealing with a small or large allocation. Unfortunately, I don't see an easy fix for this. Do you have any suggestion, or should I just give up on using malloc_usable_size()? As an aside: regardless of my purely educational exercise, what do you guys think of putting such checks in the libc itself? The performance impact is relatively small, and the benefits in terms of detecing and preventing heap buffer overflows huge. That's all the more important with jemalloc, which is (relatively) less safe that phkmalloc in fact of such attacks. Bye, Andrea 1: http://www.cs.umass.edu/~emery/pubs/06-28.pdf -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it.Received on Sun Sep 23 2007 - 09:34:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC