From: barmar@think.com (Barry Margolin)
Newsgroups: comp.security.misc
Subject: Re: rexd security concerns
Date: 5 Feb 1993 20:50:11 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Message-ID: <1kuju3INNil@early-bird.think.com>
References: <1993Feb4.183533.16522@medtron.medtronic.com>

In article <1993Feb4.183533.16522@medtron.medtronic.com> ds0007@medtronic.COM (Dale Skiba) writes:
># The rexd server provides only minimal authentication and is often not run
># by sites concerned about security.
> 
>Could anyone share what these authentication problems are?

Rexd does *no* authentication other than disallowing execution as root.  It
simply believes the uid and gid in the credentials.  It doesn't even
require the client to be in hosts.equiv or ~/.rhosts, nor does it check for
"privileged" port use.

>Also, how does this relate to rexecd.  rexd is the RPC-based remote
>execution server and rexecd if the remote execution server.  These
>appear to be two seperate C interfaces.  The security breaches of
>rexecd are well documented, but I can't find anything on rex.

Rexecd requires the user's password to be transmitted, so it's about as
secure as telnet (i.e. it allows passwords to be captured by someone
snooping on the wire).

Rshd is between rexd and rexecd in security.  It uses hosts.equiv and
~/.rhosts and requires the use of a source port between 512 and 1024 (these
are privileged on Unix).  Assuming the hosts in hosts.equiv and all
~/.rhosts files are actually trustworthy, it can still be spoofed by a PC
that can alter its address to be that of one of the trusted hosts.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar