Gerardo Richarte wrote:
> > 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.
> >
>
> Sorry for my bad english, I think that this is the problem why you
> misunderstood what I'm trying to say... I'll try to explain it again.
I'll try to explain again: you are over-writing function pointers.
StackGuard does not defend function pointers. Yes, this is a legitimate
vulnerability, but it is a vulnerability beyond the scope of the
StackGuard tool.
StackGuard is intended to defend function activation records, and
nothing more. Emsi's hack found a way to corrupt an activation record
without StackGuard detecting it. StackGuard 1.21 closes that
vulnerability, and so we are back to our original claim: you can't use
a buffer overflow to corrupt the return address of a function pointer
without StackGuard detecting it.
> with the first gets(a) it overwrites just p, so it points to 0x4010022c
> that is the address in memory of libc's __exit_funcs[0].func.at (look
> forward for exit()'s source code), a pointer to a function that will be
> called by libc's exit().
Precisely: libc's __exit_funcs[0].func.at is a FUNCTION POINTER, and
therefore Not a StackGuard Issue. For instance, the following code is
also vulnerable
under StackGuard:
myfunc(void (*virt_func )) {
void (*foo)() = virt_func;
char buf[25];
gets(buf); // overflow buff, corrupt foo ptr
foo(buf); // wanna call foo, end up calling attack code
)
As I've said before, we are working on a tool called "PointGuard" that
will actually attempt to address this problem.
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:12:09 PDT