[SUMMARY] Vulnerabilities in solaris in.rarpd (can I disable?)

Wanted to know when in.rarpd can be turned off, since a recent
advisory claiming local and remote vulnerabilities was posted.
My original question and the advisory follow.

in.rarpd is the daemon which determines IP addresses based on MAC 
addresses.

I only have two systems running in.rarpd, one is a SunRay server (hence
also a DHCP server) and the other is a Jumpstart server.

in.rarpd is required for boot servers (eg. Jumpstart or network boot), 
and if /tftpboot exists it will be started (see /etc/init.d/nfs.server). 
Many fire it up when installing servers via Jumpstart, then kill it.

Three folks claim that a DHCP server would require rarp, and I would tend
to agree; one claimed it would not.

Note that in.rarpd is a daemon, it is not started by inetd as a few
suggested. To disable it you must ensure /tftpboot doesn't exist so
it does not get started in /etc/init.d/nfs.server (or modify that
script). This disables bootp and therefore Jumpstart and (I believe)
DHCP as well.

I'll include Casper Dik's reply in it's entirety:

   My personal belief after examination of the code is this:

	- the routines in question are buggy
	- the routines in question are *always* called with fixed
	  parameters and exploitig them does not appear to be possible.

   Furthermore, rarp requests cannot pass routers and therefore
   the "remote" in the exploit is on directly attached networks.

   RARP is only used for network based installs (boot net - install)
   and other network booting (diskless)

   Casper
   
   
Thanks to:

topher
Tim Evans
Casper Dik
Michael Schulte
Jeff Kennedy
Jay Lessert
Michael Hocke
Dragon King

> 
> Just saw this advisory for in.rarpd, claims of local and remote
> vulnerabilities.
> 
> So my question is, can this be disabled? The daemon is only
> running on two of our systems, one is a SunRay server and the
> other is our NIS master, and I can't afford to break either.
> A preliminary search for information hasn't yielded anything useful, 
> and I'd like to resolve this asap if you know what I mean.
> 
> Thanks.
> 
> Dave Foster
> 
> > Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
> > X-Originating-IP: [144.134.252.220]
> > From: "david evlis reign" <davidreign@hotmail.com>
> > To: bugtraq@securityfocus.com, vulnwatch@vulnwatch.org
> > Subject: [DER Adv #7] - Multiple Vulnerabilities in solaris in.rarpd
> > Date: Wed, 22 May 2002 02:06:43 +0000
> > Mime-Version: 1.0
> > 
> > Intro:
> > rarpd is a reverse arp protocol for small to medium sized networks.
> > in the solaris implementation (in.rarpd) there seems to be 3 remotely 
> > exploitable buffer overflows, 2 locally exploitable and 2 cases of format 
> > string exploitability.
> > 
> > Details:
> > In the functions error and syserr (syserr also being used by other in.* 
> > implmentations which are also exploitable, but not the topic of this 
> > advisory today) there contains 2 common syslog calls without format strings.
> > 
> > static void
> > syserr(s)
> > char    *s;
> > {
> >         char buf[256];
> > 
> >         (void) sprintf(buf, "%s: %s", s, strerror(errno));
> >         (void) fprintf(stderr, "%s:  %s\n", cmdname, buf);
> >         syslog(LOG_ERR, buf);
> >         exit(1);
> > }
> > 
> > /* VARARGS1 */
> > static void
> > error(char *fmt, ...)
> > {
> >         char buf[256];
> >         va_list ap;
> > 
> >         va_start(ap, fmt);
> >         (void) vsprintf(buf, fmt, ap);
> >         va_end(ap);
> >         (void) fprintf(stderr, "%s:  %s\n", cmdname, buf);
> >         syslog(LOG_ERR, buf);
> >         exit(1);
> > }
> > 
> > there are two vulnerable calls which could be exploited locally or remotely.
> > 
> > vendor notification: nope
> > 
> > a working exploit has been created for the remote buffer overflows but not 
> > this time, not here.
> > 
> > DER systems
>    << All opinions expressed are mine, not the University's >>
> 
>   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>    David Foster    National Center for Microscopy and Imaging Research
>     Programmer/Analyst     University of California, San Diego
>     dfoster@ucsd.edu       Department of Neuroscience, Mail 0608
>     (858) 534-7968         http://ncmir.ucsd.edu/
>   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
>    "The reasonable man adapts himself to the world; the unreasonable one
>    persists in trying to adapt the world to himself.  Therefore, all progress
>    depends on the unreasonable."   -- George Bernard Shaw
> _______________________________________________
> sunmanagers mailing list
> sunmanagers@sunmanagers.org
> http://www.sunmanagers.org/mailman/listinfo/sunmanagers


   << All opinions expressed are mine, not the University's >>

  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   David Foster    National Center for Microscopy and Imaging Research
    Programmer/Analyst     University of California, San Diego
    dfoster@ucsd.edu       Department of Neuroscience, Mail 0608
    (858) 534-7968         http://ncmir.ucsd.edu/
  =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

   "The reasonable man adapts himself to the world; the unreasonable one
   persists in trying to adapt the world to himself.  Therefore, all progress
   depends on the unreasonable."   -- George Bernard Shaw
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers