Vulnerability Development mailing list archives
Re: glibc glob_filename() recurse call stack overflow (Re[2]: Bash Blues)
From: spacewalker <spacewalker () altern org>
Date: Sun, 16 Feb 2003 11:19:16 +0100
[Moderators : please ignore my previous message it is quite incomplete] Hi, On Sat, 15 Feb 2003 13:30:04 -0800 (PST) Vladamir Shmirnov <red_vigil () yahoo com> wrote:
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).
Look what does say gdb about it : 0x80a6e6d <glob_filename+97>: sub %eax,%esp 0x80a6e6f <glob_filename+99>: mov %esp,0xfffffff8(%ebp) 0x80a6e72 <glob_filename+102>: add $0xfffffffc,%esp 0x80a6e75 <glob_filename+105>: push %edi <- crashes here (gdb) info register eax eax 0x1e60 7776
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?
First of all, as every library glibc shares everything with user process. It is not exploitable at all because, in opposite to what has been said about it, that's not a stack overflow. I'd like also to make you see that the process adress space IS NOT glibc, but well the function glob_filename into bash. I successfully tested the problem under solaris/sparc, as well as linux/x86. Let's explain a little on how does work stack under x86 : it's a part of memory pointed by the esp register, which grows down by the program execution. A call to alloca asks the esp register to be lowered from an userinput value. Now, let's see how kernel manages usermode stack : kernel looks for pagefaults (invalid or valid but missing page accesses). It includes the case of when the stack needs a new page because it has grow down. In this special case, note that 7776 is much bigger than a complete page (4096 bytes) and so the alloca asked for 2 pages at one. Only, it accesses the second one before the first, and as the kernel hasn't allocated the first one before, it crashes. Now, let's see why it does crash under linux and solaris/sparc (as well as hpux) but not under BSD ? libc is bad answer. It only depends on the way the operating system manages the missing pages in stack adressing, and it looks like BSD is more tolerant for big instant allocations. Well, it has no reason of accepting such big allocations on the stack. In resume, that's not exploitable at all, not much more than null pointers :) Happy afternoon spacewalker
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)