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

From: spacewalker (spacewalker@altern.org)
Date: 02/16/03

  • Next message: Adam Gilmore: "RE: A different bash blues" 
    Date: Sun, 16 Feb 2003 11:19:16 +0100
From: spacewalker <spacewalker@altern.org>
To: Vladamir Shmirnov <red_vigil@yahoo.com>

    [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

    Relevant Pages

    • Re: Trouble with ptrace self-attach rule since kernel > 2.6.14
      ... Since my code should be portable across a large range of different glibc and kernel versions, I had to accommodate this behavior by either 1) allocating the new thread's stack within the old thread's stack, effectively sharing "errno", or 2) making direct system calls and avoiding all functions that access "errno". ...
      (Linux-Kernel)
    • For those with Intel Centrino 2200BG wireless...
      ... 2200BG 802.11b/g miniPCI card, you can now use this card with the ... The FreeBSD kernel stack is 2 pages (8192 bytes on ... alloca() will overflow the stack and kill the kernel. ...
      (freebsd-current)
    • Re: Sparse warning: bitmap.h: bad constant expression
      ... and gcc handles it by itself w/o calling alloca(). ... > kernel stack, but that doesn't make them illegal per se. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [Full-disclosure] PHRACK 64: ATTACKING THE CORE
      ... - The Slab Allocator ... - Slab overflow exploiting: ... - Forcing a kernel path to sleep ... - Stack Frame Flow Recovery ...
      (Full-Disclosure)
    • Re: What is a stack frame?
      ... There is no need for a separate "this frame" pointer. ... In any case, the more general term, which covers what a C compiler ... hardware-provided stack to implement the stack-like data structure ... manner since the current stack frame is "deformed" by alloca. ...
      (comp.lang.c)