Sophisticated but nasty rcmd bug

[Alan Cox <alan@cymru.net>]

I normally wouldnt send something like this one without PGP but its
pretty serious and really needs a fast fix. There is a FreeBSD exploit 
program out already that if Linux has got this bug is not going to be 
very hard to port... So while complex it is automated.

-------


The reporter's message appears below. The reporter mentions the
library routine rcmd.c used by clients such as rsh and rlogin. We
would be interested in your thoughts as to whether this or similar
library routines you may use are vulnerable, as well as any plans you
may have for a solution.



Vulnerability in unchecked DNS data.

In research for our upcoming network auditing tool, we have uncovered a
serious problem in many resolver implementations which trust invalid
data sent to them.  This vulnerability specifically applies to hostname
to address resolution.  When a standard hostname lookup is performed on
internet connected systems, the resulting address will, and should be,
4 bytes.  (Forgetting about IPv6 for now).  Assuming that the address will
always be 4 bytes, many privileged and unprivileged programs (including
network daemons) trust the address length field which is returned from
gethostbyname() in the hostent structure.  By trusting the length field
returned by DNS to be 4 bytes, it then copies the address into a 4 byte
address variable.  We have found that by sending a large address to many
programs, an overflow occurs.  We do not have the resources to test all
operating systems at this time (however assuming that the standard BIND
resolver is being used, we would assume most (if not all) are vulnerable).

An example of this vulnerability occurs in rcmd.c, the standard
library routine which is used by rsh and rlogin to remotely connect
to systems.  The faulty code within this routine follows:

   hp = gethostbyname(*ahost);
   if (hp == NULL) {
      herror(*ahost);
      return (-1);
   }
   *ahost = hp->h_name;

   .
   .
   .

   bzero(&sin, sizeof sin);
   sin.sin_len = sizeof(struct sockaddr_in);
   sin.sin_family = hp->h_addrtype;
   sin.sin_port = rport;
   bcopy(hp->h_addr_list[0], &sin.sin_addr, hp->h_length);

In this example, we copy hp->h_length ammount of data into the
address variable of a sockaddr_in structure, which is 4 bytes.
The hp->h_length variable is taken directly from the DNS reply
packet.  If we now look at how rcmd() declares it's variables,
and after looking through rlogin with a debugger, we can determine
that this is an exploitable condition.

   int rcmd(ahost, rport, locuser, remuser, cmd, fd2p)
        char **ahost;
        u_short rport;
        const char *locuser, *remuser, *cmd;
        int *fd2p;
   {
        struct hostent *hp;
        struct sockaddr_in sin, from;
        fd_set reads;

On further testing, and implementation of exploitation code, we can
verify that this is indeed possible.

victim$ whoami
oliver
victim$ rlogin -K random-domain.com
random-domain.com: Connection refused
# whoami
root
#

Without the -K rlogin would attempt to use krcmd, the kerberos version.
(Test was done on OpenBSD).  Meanwhile on attacker, we've started up the
program to send a fake DNS reply.

attacker# ./dnsfake
victim.secnet.com(4732)->dns.secnet.com(53) : lookup: random-domain.com (1:1)
sent packet fake reply: 270 bytes
dns.secnet.com(53)->victim.secnet.com(4732) : reply: random-domain.com (1:1)

This message has only been sent to vendors and other organizations who
may be responsible for fixing their implementations, and is not public
information (as far as we know).  This also applies to remote daemons,
especially when we consider that all (known) implementations of the BIND
resolver start _res.id at 1 (the ID of the query), (this seems to have been
been changed in the latest release).  All that is left to guess is the
originating port number of the query.