Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues)

[Vladamir Shmirnov <red_vigil () yahoo com>]

  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 <3APA3A () SECURITY 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-dev () securityfocus 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