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. 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
This archive was generated by hypermail 2b30 : Sun Feb 16 2003 - 10:15:02 PST