Gerardo Richarte wrote:
> I think that having this kind of overflow available, StackWard is
> still vulnerable to a little smarter attack.
I assume you mean "StackGuard". I've never heard of StackWard, and
neither has Altavista. If someone needs a catch project name, "stackward"
seems to be available :-)
> You may think that this code example is too tricky, but there was a
> buffer overflow in bind's inverse query
> (http://www.securityfocus.com/vdb/bottom.html?vid=134) like this. This
> makes me remember of some code I wrote to exploit this for Sparcs, as
> it was just one call deep, it was imposible to overwrite the return
> address, so, by using a memcpy() to a pointer I could overwrite (like
> that one in
> the example code) I overwrited part of the libc in memory, lets say
> printf, so when the program called printf() after the second memcpy(),
> instead of calling the original printf() it called my code: Here you
> have an exploit that can be used still if you have StackWard.
You appear to be describing a buffer overflow that attacks a pointer, and
not the activation record. StackGuard only claims to protect the
activation record, so while this is a legitimate vulnerability that
StackGuard does not prevent, it is not actually a bug in StackGuard.
We are developing a future product called "PointGuard" that will try to
apply StackGuard-style integrity checking to code pointers, but it is a
long way from ready. If I understand your bind vulnerability correctly,
it is the kind of thing that PointGuard would be able to defend against.
Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
