Re: RADIUSD: Big security holes

Dave Kennedy (davek@muscle.net)
Wed, 4 Sep 1996 09:27:44 -0400 (EDT)

Earlier this morning I wrote ...
> Kevin Kadow writes...
> > Although RDIST suggests running 'radiusd' chroot, chroot is not a
> > panecaea for security holes that yield root. Ideally the program would
> > bind the radius and radacct ports, chroot, then run setuid as a unique,
> > unprivileged user (like some HTTPDs), preferably a user that isn't
> > allowed to rlogin... (see why below).
>
> I don't run radiusd as setuid on my system where most buffer overflow
> issues arise. Is this hole exploitable over the network? By writing
> "executable" data that adds an entry to the password file or something
> like that?
>
> Unfortunately, my imagination isn't what it used to be. :) I don't see
> how this would be exploitable over a network.

Looking at this even further, this doesn't look like much of a
hole. The code in question is:

/* Patched code */
hp = gethostbyaddr((char *)&n_ipaddr, sizeof (struct in_addr), AF_INET);
strncpy(hostnamebuffer, hp->h_name, 99);
return(hostnamebuffer);

vs.

/* Unpatched code */
return(hp->h_name);

Note that hp is set by a call to gethostbyaddr(). If DNS is being used,
doesn't this mean someone's IN-ADDR database would have to be compromised?
Also, what could be passed via a DNS hostname that could exploit a buffer
overflow? If DNS is not being used, wouldn't /etc/hosts have to be
compromised? If so, you're already hosed.

OK - I've looked at this for all of 5 minutes. What am I missing? Or
is this not really a security hole?

davek

-- 
| Dave Kennedy (davek@muscle.net)             Voice: 770-368-1514 |
| Multi-User Systems, Inc.      Putting MUSCLE in Internet Access |