Re: Buffer overrun in Redhat 5.0 (fwd)
Hi,
This concerns a potential buffer overrun problem with glibc2 -- wanted to
make sure that the relevant Debian people were aware of it. I'm not
running a hamm system anymore so I can't test it against the Debian libc6.
TL
---------- Forwarded message ----------
From: Wilton Wong - ListMail <listmail@nova.blackstar.net>
To: BUGTRAQ@NETSPACE.ORG
Date: Mon, 15 Dec 1997 06:57:45 -0700
Subject: Re: Buffer overrun in Redhat 5.0
So far I've gotten a few reports back saying that my trace_sehll program
doesn't work as expected, all I can say is it worked for me. In most cases
it just returned "XXX..XXX: host unknown" or something similar..
BUT if you increased the buffer size the programs still segfaults,
although they do not immediatly yield a root shell..
A buffer overrun != a root shell in all cases, although in about 99% of
them they do, the problem is finding the right spot to put the shellcode
or whatever it is that you want the thing to return..
Getting root is not important here, what is important is that there is a
buffer overrun and you can get at it, whether or not you can get a shell
out of it is irrelavent, a buffer overrun is shoddy programming on
someone's part and that's the real problem not if you can get root or
not. Root is just a bonus, and yes it's nice but..
Story thus far:
Okay I noticed that if I ran tracroute with a really long param it
segfaults and I wondered if I could exploit this, I could, I checked to
see that I didn't have a twisted version of traceroute, I didn't, so I
tried ping as well same result. That's when I posted.
Then almost immediatly afterward I also notice rsh and rlogin as they too
were suid and I posted that too..
Then I noticed I could also segfault telnet.. that was odd..
I downloaded sources for all of there and built them myself and scanned
thru most of the code to see if there were any obviuos holes there wern't
I wasn't expecting to find any as these program come standard with almost
every OS.
The problem lise deep within one of the libraries.. glibc2 joy... the
programs themselves are not vulnerable. For example a simple program like
this should in no cases yield a segfault:
vulnerable.c
----------------
#include <netdb.h>
void main(int argc, char *argv[]) {
struct hostent *hostinfo = 0;
if (argc > 1) {
hostinfo = gethostbyname(argv[1]);
}
if(hostinfo)
printf("Host name: %s\n", hostinfo->h_name);
}
----------------
but it can be made to segfault with a extra long parameter..
The gdb output wasn't much help:
---------------
wwong@nova:~/src/test$ ./vulnerable `buff-over`
Segmentation fault (core dumped)
wwong@nova:~/src/test$ gdb vulnerable core
GDB is free software and you are welcome to 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.
GDB 4.16 (i386-redhat-linux), Copyright 1996 Free Software Foundation,
Inc...
Core was generated by `./vulnerable
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error
#0 0x2e726174 in ?? ()
(gdb) bt
#0 0x2e726174 in ?? ()
#1 0x74656e in ?? ()
Cannot access memory at address 0x736b6361.
(gdb) quit
wwong@nova:~/src/test$
---------------
Ahh.. symbolic names of ?? and ?? I know what that is brilliant!!
But the strace of it shows that before the program segfaults it opens
libresolve, and I suspect that is where the overrun lies..
Why it will yield a root shell for me and not for you I don't know..
could be a million number of things all I know is that there is a buffer
overrun and for me it is exploitable... =)
- Wilton
-------------------------------------------------------------------------
Wilton Wong BlackStar Communications
URL: http://www.blackstar.net 16121 - 57 Street
Email: wwong@blackstar.net Edmonton AB T5Y 2T1
Tel: (403) 486-7783 Fax: (403) 484-6004
-------------------------------------------------------------------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: