strange limitation on rcmd()

On Fri, Jul 07, 2006 at 08:30:01PM -0400, Mikhail Teterin
wrote:
> The manual page says, that rcmd() is only to be used by
root's processes.

DESCRIPTION
     The rcmd() function is used by the super-user to
execute a command on a
     remote machine using an authentication scheme based on
reserved port num-
     bers.

Note that only root can bind to reserved ports.

> On other OSes (Solaris, AIX), trying to call rcmd()
without being root simply 
> fails.
> 
> FreeBSD, however, tries to be helpful and invokes
rcmdsh in this case, which 
> is inefficient and leaves the stderr's filedescriptor
(fd2p) unfilled.
> 
> Why?
> 
> My understanding is, this is to make it harder for
would-be attackers to 
> attack machines with .rhosts-based security. But that
is nothing more than a 
> bad band-aid anyway -- attacker's own implementation
of rcmd() (without the 
> geteuid() checks) is trivial...

But an attacker who doesn't have root won't be able to use
their own
implementation of rcmd(). It will just fail. Either the
attacker will ask to
bind to a privileged port (which will fail at the local
host), or they will
bind to a non-privileged port (in which case the remote host
will reject the
request)

rsh is a setuid root binary. It is able to bind to
privileged ports, whilst
performing security checks that the requested access is
valid. In the same
way, the 'passwd' command lets you change your own
password, without letting
you change someone else's.

> So, without providing any meaningful security
improvement (who is relying 
> on .rhosts for security anyway?!), we are impeding a
very useful 
> functionality.

No security improvement is implied. Rather, you just get
extra
functionality. Instead of a dead failure, certain non-root
requests are
allowed (i.e. user A on host X can run commands as user A on
host Y)

> rcmd offers an efficient way to send your data to a
command "abroad" and even 
> has a mechanism for getting the remote's stderr --
assuming, your network is 
> secure enough for you to trust .rhosts.

And the requesting user is running as root, so they can bind
to a privileged
port.

> Why are we duplicating the misguided efforts of
commercial Unixes and limiting 
> it to root only?

Because this is exactly how the .rhosts security model works
- it accepts
requests only from privileged ports, which in turn means
that it knows the
request only came from root.

This mechanism is only valid for trusted hosts, of course.
If you allow a
random person to put their own PC on the network, they can
of course send
packets from privileged ports (either by installing Unix
with their own root
password, or by installing DOS and sending packets which
come from
privileged ports)

HTH,

Brian.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

Brian Candler wrote:

> Note that only root can bind to reserved ports.

...

> This mechanism is only valid for trusted hosts, of
course. If you allow a
> random person to put their own PC on the network, they
can of course send
> packets from privileged ports (either by installing
Unix with their own root
> password, or by installing DOS and sending packets
which come from
> privileged ports)

I gather that it is now possible to disable the
privileged ports thing on FreeBSD at least.

(Thank heavens, I say 

iang
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On 2006.07.10 16:07:06 +0200, Iang wrote:
> Brian Candler wrote:
> 
> >Note that only root can bind to reserved ports.
> 
> ...
> 
> >This mechanism is only valid for trusted hosts, of
course. If you allow a
> >random person to put their own PC on the network,
they can of course send
> >packets from privileged ports (either by installing
Unix with their own 
> >root
> >password, or by installing DOS and sending packets
which come from
> >privileged ports)
> 
> I gather that it is now possible to disable the
> privileged ports thing on FreeBSD at least.
> 
> (Thank heavens, I say 

Actually it is, but it would obviously be a stupid idea to
do so any
place where privileged ports are required...

[simonzaphod:~] sysctl net.inet.ip.portrange.reservedhigh
net.inet.ip.portrange.reservedlow
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.reservedlow: 0

-- 
Simon L. Nielsen

On Monday 10 July 2006 10:17, Simon L. Nielsen wrote:
= Actually it is, but it would obviously be a stupid idea to
do so any
= place where privileged ports are required...

It would be. But where they are NOT required, it is stupid
to check the 
geteuid() inside the client's rcmd 

Thank you very much for your explanation, Brian, rsh being
an SUID is 
something I overlooked.

What I remain upset about, though, is that the rcmdsh(),
which is used by 
rcmd() ignores the fd2p parameter making it impossible to
capture the 
remote's stderr...

Yours,

	-mi
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

On Mon, Jul 10, 2006 at 11:47:33AM -0400, Mikhail Teterin
wrote:
> What I remain upset about, though, is that the
rcmdsh(), which is used by 
> rcmd() ignores the fd2p parameter making it impossible
to capture the 
> remote's stderr...

Well, it's probably worth send-pr'ing it.

I'd first test whether rsh itself forwards stderr properly.
Maybe there's
some underlying reason why rcmdsh doesn't have an fd2p
argument.
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"

понед╕лок 10 липень 2006 13:50, Brian Candler написав:
> Well, it's probably worth send-pr'ing it.

The rcmdsh() is taken from OpenBSD, I think, and has no room
for the stderr. 
One would need to reimplement something like rcmdsh2() first


> I'd first test whether rsh itself forwards stderr
properly. Maybe there's
> some underlying reason why rcmdsh doesn't have an fd2p
argument.

     The rsh utility copies its standard input to the remote
command, the
     standard output of the remote command to its standard
output, and the
     standard error of the remote command to its standard
error.

ssh seems compliant too. The signal-handling is different,
though:

     Interrupt, quit and terminate signals are propagated to
the remote
     command;

Whereas with rcmd one just writes the signal number (any
signal number) into 
the fd2 descriptor...

I think, rcmd() should just try to connect and leave it to
the remote to 
reject it based on the too-low port number or anything.

Another approach would be to use a separate suid utility
(Linux has rcmd(1), 
for example), with semantics more closely matching those of
rcmd(3).

The reason I like rcmd() is that it lets me send data to a
remote machine a) 
_directly_ from my program; and b) without also implementing
the server side.

I could achieve both of these with a non-root process by
disabling 
the "isroot" checks inside the rcmd and by
configuring the server to accept 
rcmd from any port. Other approaches require the root's
setuid bit on the 
program, or abandoning the _directness_ of the a) by copying
many gigabytes 
through the client's memory buffers a couple of extra
times.

	-mi
_______________________________________________
freebsd-securityfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-secu
rity
To unsubscribe, send any mail to
"freebsd-security-unsubscribefreebsd.org"