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?

    - Josh

--- 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
> 3500'`
> >> <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
>
>
>
> --
> ~/ZARAZA
> Áðîñüòå ñòàðàòüñÿ - íè÷åãî èç ýòîãî íå âûéäåò.
> (Òâåí)
>

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]