On Fri, Apr 05, 2002 at 05:21:19AM -0500, Anthony DeRobertis wrote:
> for (x = 0; x < 10000; ++x) {
> ptr = malloc(123456);
> free(ptr);
> free(ptr);
Thought experiment: Allocate 1 million x 1 Kb chunks, free them but
keep the pointers. Now allocate 1 million x 1 Kb chunks but hang on
to them. Now free the first lot of pointers again. How does the system
know that this is a double free() ?
Maybe someone can explain to me how they distinguish between 0x4007fec0
which is a pointer to a 512 byte struct that I just alloc'ed, and
0x4007fec0 which is a pointer to a 64Kb buffer that I free'd half an
hour ago ? I think the answer is "they don't" and therefore this
"protection" is a nice developer's diagnostic but not a protection
feature for users.
Has anyone analysed the zlib bug and checked that exploits MUST trigger
double free protection on BSD? Or is this just supposition based on
black box testing and not much real thought? What about multi-threaded
apps where the zlib calls may be happening in tandem with other code
that uses the allocator?
Maybe more people should re-read the OpenBSD security philosophy. All
bugs are potential security holes. Fix the bugs.
Nick.
This archive was generated by hypermail 2b30 : Mon Apr 08 2002 - 20:40:16 PDT