I looked onto your site for a few seconds and saw that you use magic values.
I'd just like to announce that we have a heap protection system for glibc available for download. The system detects and prevents all heap overflow exploits that modify inline control information from succeeding against a protected application, can be installed system-wide or on a per-process basis using LD_PRELOAD, and is transparent to existing applications.
Nice advertisement but you should underline the fact, that it only protects against glibc malloc()/free() problems. There are a number of software packages that implement their own heap wrappers or work with linked lists. They still are vulnerable to heap overflows. f.e. PHP.
And on the other hand there is a much simpler way to protect any unlink from a linked list from ever beeing exploited.
1.5 years ago I added code to my glibc (and to the PHP malloc/free wrappers (only on my system cause PHP group wanted this code not in official Zend Engine)) that simply checks on unlink if my backward pointed block really points with his forward pointer to me and if my forward pointed block points with his backward pointer to me. This makes the unlink process unexploitable, while your approach is still attackable if someone guessed the magic value. (Even if that sounds unrealistic it is still possible.)
The unlink macro would then look like
#define unlink(P, BK, FD) { \
FD = P->fd; \
BK = P->bk; \
if (FD->bk != P || BK->fd != P) ATTACK_ON_UNLINK; \
FD->bk = BK; \
BK->fd = FD; \
}(I am writing this down from my memory, I have the code not here at the moment)
Stefan Esser
