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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:11:10 PDT