Vulnerability Development mailing list archives
Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues)
From: "Roland Postle" <mail () blazde co uk>
Date: Sun, 16 Feb 2003 01:54:06 +0000
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
Current thread:
- Bash Blues. uk2sec (Feb 13)
- Re: Bash Blues. Andrew Walkingshaw (Feb 13)
- Re: Bash Blues. Kurt Seifried (Feb 14)
- Re: Bash Blues. Dack (Feb 14)
- Re: Bash Blues. Roland Postle (Feb 14)
- glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues) 3APA3A (Feb 15)
- Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues) Vladamir Shmirnov (Feb 15)
- Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues) Roland Postle (Feb 16)
- Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues) spacewalker (Feb 16)
- glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues) 3APA3A (Feb 15)
- Re: Bash Blues. Andrew Walkingshaw (Feb 13)
- Re: Bash Blues. TerraTrans Security (Feb 14)
- A different bash blues admin (Feb 15)
- RE: A different bash blues Adam Gilmore (Feb 16)
- A different bash blues admin (Feb 15)
- RE: Bash Blues. Adam Gilmore (Feb 14)
- Re: Bash Blues. Peter Pentchev (Feb 14)