[12577] in bugtraq
Re: Vulnerability in ImmuniX OS Security Alert: StackGuard
daemon@ATHENA.MIT.EDU (Crispin Cowan)
Sun Nov 14 00:52:19 1999
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <382D8290.B0E5EA44@cse.ogi.edu>
Date: Sat, 13 Nov 1999 15:24:00 +0000
Reply-To: crispin@CSE.OGI.EDU
From: Crispin Cowan <crispin@CSE.OGI.EDU>
X-To: Gerardo Richarte <core.lists.bugtraq@CORE-SDI.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
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