Re: Fwd: Bug#21810: libc6: rexec call dumps core with user="string" and password=NULL

["Andrew Morton" <morton at nortelnetworks dot com>]

Mark Kettenis wrote:
> 
>    From: Andreas Schwab <schwab@suse.de>
>    Date: 26 Oct 1999 19:50:35 +0200
> 
>    Both Solaris 5.5.1 and SunOS 4.1.4 implement it.
> 
> Well, I would certainly call SunOS 4 historic by now.

SunOS 5.6 prompts.
HPUX 10.20 prompts.
AIX 4.1.5 prompts.
Linux libc5 prompts. (http://www.uow.edu.au/~andrewm/ruserpass.c)
From the manpage, VMS prompts.

> Anyway, the issue has been discussed before [1].  Ulrich thinks
> we should stay with the BSD 4.4 implementation, and I agree with him.
> It's more or less the reference standard for rexec().

It's broken.

As it stands, this bug makes rexec(3) with NULL user/pass quite, quite
useless.  This is because it has two possible behaviours:

1: A match is found in .netrc: rexec(3) uses it
2: No match is found in .netrc: rexec(3) segfaults.

How can you possibly use this, without having earlier called
getuserpass() to determine whether or not rexec(3) is going to core? 
It's silly.

Either fix the bug or go incompatible and handle the null return from
getuserpass() to avoid the segfault.  Bug-for-bug compatibility with BSD
doesn't seem pointful.  

> Also note that rexec() is considered to be pretty dangerous.  FreeBSD
> and NetBSD only offer it for compatibility with BSD 4.4, and
> reccommend using another mechanism.

For a trusted LAN environment, behind a firewall, with many Unix
variants, none of which ship SSH: it's very useful.


I agree that popping up a prompt from within rexec() is rather
obnoxious, but that's the API. Caveat emptor.  Pass in a user/pass to
prevent it, just as you would to prevent a segfault from the GNU
implementation.



Semi-OnT:

Please be aware that there's another problem with this stuff:


In the wire protocol for rexec the client sends down a port number. 
This port represents the backchannel upon which the client is receiving
stderr output.  The server attempts to open that port on the client
*prior to authentication*.

Some time ago some bright spark realised that this could be used for
indirect portscanning and an attempt was made to change the wire
protocol.  The backchannel is only opened *after authentication*. 
Current redhat rexecd's are done this way.  Unfortunately:

- The wire protocol changes were not made to the client end (glibc).

- Consequently all Linux rexecd's can deadlock.  'rexec -a' is the
workaround.

- The fix is *not* to fix the client because Linux then won't work with
other unixes.

- The fix is to verify (within rexecd) that the connected-to port is not
privileged.  If it is privileged, or if the connection to the client is
refused, drop a security log amd bale.

- RedHat and variants will cause extra pain because their rexecd's vary
from the upstream versions (they've added PAM).


I was going to fix all this up mid-year, but for obvious reasons I've
lost interest.