Full Disclosure mailing list archives
/bin/mail & glibc
From: uk2sec () oakey no-ip com
Date: Thu, 29 May 2003 09:34:14 +0100 (BST)
Hi, 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` root@localhost 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 details. 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? cheers, _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- /bin/mail & glibc uk2sec (May 29)
- <Possible follow-ups>
- Re: /bin/mail & glibc Mark (May 29)