Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Vladamir Shmirnov (red_vigil_at_yahoo.com)
Date: Sat Feb 15 2003 - 15:30:04 CST
I came to the same deliberations, that it is in fact
a bug in glibc. In the bash source file
lib/glob/glob.c, in functiong glob_filename(), the
call to bcopy(3) with an extraordinarily long length
of source string causes the crash. However, I may
note that although I haven't researched this it seems
that it could possibly be a bug caused indirectly by
the preceding call to alloca(3).
If it is a problem with glibc then other programs
are vulnerable, including SUID root, correct? Also,
if it is a problem with glibc, it is not exploitable
from user space, or is it?? Does glibc share the
stack with the user process?
--- 3APA3A <3APA3ASECURITY.NNOV.RU> wrote:
> Dear Roland Postle,
> It looks to be the only correct post in this
> thread :) Yes, it's
> definitely bug in glibc, not in bash itself (same
> versions of bash on
> libc systems like FreeBSD are not affected). Recurse
> call stack overflow
> is believed not to be exploitable to code
> execution, but since this bug
> is in library it may be treated as security one as
> it may be exploited
> remotely (at least as a DoS) in a case
> glob_filename is used in some
> network service.
> --Thursday, February 13, 2003, 8:34:36 PM, you wrote
> to vuln-devsecurityfocus.com:
> >>During some work, I noticed GNU bash could be
> crashed by sending a
> >>malformed perl request to the terminal.
> >> example: `perl -e 'print "*/*" x
> >> <bash crashes>
> RP> It's a stack overflow, due to glob_filename (in
> glob.c) recursively
> RP> calling itself while parsing the filename. So
> probably not exploitable.
> RP> - Blazde
> Бросьте стараться - ничего из этого не выйдет.
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day