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

I don't think this is a glibc issue. glibc does indeed have a glob_filename, but when I checked the other day it had a 'depth' parameter that was incremented with each recursion, presumably to prevent stack overflows. The one I was reffering to is in bash-2.05b\lib\glob\glob.c in the bash source tree which begins:

/* glob.c -- file-name wildcard pattern matching for Bash.

[Copyright notice]

/* To whomever it may concern: I have never seen the code which most

   Unix programs use to perform this function. I wrote this from scratch

   based on specifications for the pattern matching. --RMS. */

Sounds to me like it's unrelated to the glibc one.

Regarding why it doesn't crash on some BSD systems, maybe they just have a bigger stack, or better exception handling.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

I think the reason it sometimes crashes in bcopy / alloca is just because it runs out of stack there instead of in the main body of glob_filename(). If you look at the call stack it'll be 99% glob_filename() calls. For example....

>eval `perl -e 'print ":;" x 97500'`

This one is a stack overflow too.

(gdb) backtrace
#0 0x080c1d3e in xmbsrtowcs ()
#1 0x080c21b5 in xmbsrtowcs ()
#2 0x080c2807 in sh_malloc ()
#3 0x08094a08 in sh_xmalloc ()
#4 0x080677ae in new_fd_bitmap ()
#5 0x080678ff in execute_command ()
#6 0x08069027 in execute_command_internal ()
#7 0x08068059 in execute_command_internal ()
#8 0x08067944 in execute_command ()
#9 0x08069027 in execute_command_internal ()
#10 0x08068059 in execute_command_internal ()
#11 0x08067944 in execute_command ()
#12 0x08069027 in execute_command_internal ()
#13 0x08068059 in execute_command_internal ()
#14 0x08067944 in execute_command ()
#15 0x08069027 in execute_command_internal ()
#16 0x08068059 in execute_command_internal ()

etc....

Anyway, on the subject of exploiting stack overflows, I'm really only familiar with Windows (where they're only exploitable under some unlikely extreme conditions). I've been told Linux 2.4 isn't exploitable, but 2.2 might be, can anyone confirm or deny? The basic strategy is probably to run of the end of the stack into some heap memory, and create fake heap control blocks, as you would in a heap overflow.

• Blazde