[Moderators : please ignore my previous message it is quite incomplete] Hi, On Sat, 15 Feb 2003 13:30:04 -0800 (PST) Vladamir Shmirnov <red_vigilat_private> 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
This archive was generated by hypermail 2b30 : Sun Feb 16 2003 - 10:19:04 PST