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 <3APA3Aat_private> 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-devat_private: > > >>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
This archive was generated by hypermail 2b30 : Sat Feb 15 2003 - 14:20:18 PST