Subject: Re: Make imap work without "rsh"

From: Mark Crispin <[email-masked]>
Date: Fri, 28 Jul 1995 13:55:28 -0700 (PDT)

Sigh.  I shouldn't answer messages when I'm annoyed, but there has been some
serious FUD and misinformation arising out of Paul Kramer's innocent question.

On Fri, 28 Jul 1995 09:24:57 -0700 (PDT), Mike Macgirvin wrote:
> >  This question would be better directed to comp.mail.pine (aka
> >  [email-masked]) as I believe it is a Pine implementation
> >  issue rather than an IMAP protocol issue.
>
> 	I won't presume that. It affects everybody.

It affects everybody who uses c-client.

This discussion therefore belongs in the [email-masked] mailing
list, although implementors of Pine, ML, and other applications which use c-
client need to be aware of the issue and address it in their applications and
to their users.  So, if you want to persue it further, please bring it up in
the c-client list.

Let me state my take on the issue, for the record.  This isn't to denigrate
the extent of the problem -- I'm painfully aware of it! -- but rather to give
the historical perspective.

At the time the rsh feature was implemented, there was a requirement for
passwordless access to an IMAP server, both for user convenience and for
security (password in the clear are doubleplus-ungood).  Kerberos would have
been better, but that wasn't an alternative at that time).

After making several tests, I observed that either an rsh request would work,
or it would be rejected right away.  The only instance of blocking/timeout
that I observed was when the target system was down, but I considered that to
be alright because the regular TCP open would block/timeout in that case
anyway.

At that time, I was completely clueless about two things:
	1) that there would be filters and TCP wrappers that would drop rsh
	   requests on the floor without any indication of rejection
	2) the rsh implementation on most systems *ignores* IP and TCP errors
	   such as "Destination unreachable" and "Connection refused"
If I had known, I wouldn't have done it that way.

Problem (2) is particularly evil, because you can't beat up the guys who wrote
the filters.  They'll say, "hey, we sent you a perfectly reasonable rejection,
it's your fault if you can't deal with it."  And they'd be right.  I don't
know what the TCP wrappers do.

I looked at the rsh source code.  rsh calls rcmd(), and golly gee, it has this
nasty little test that says, in effect, "TCP rejection, sleep and try again,
increasing the sleep period by a power of 2 each time":
        for (timo = 1, lport = IPPORT_RESERVED - 1;;) {
		. . .
                if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) >= 0)
                        break;
                (void)close(s);
		. . .
                if (errno == ECONNREFUSED && timo <= 16) {
                        (void)sleep(timo);
                        timo *= 2;
                        continue;
                }
For IP rejections (which is what many filters cause), it just tries again
without sleeping!  Those who know me can envision the rather colorful
commentary I would have on the geneology of the programmer responsible for
that code.  ;-)  This unfortunate code is in virtually every rsh
implementation.  And, since rsh needs to run as a privileged program, it's
effectively outside of the scope of anything that can be fixed in c-client.

OK, so we now know that rsh is not a robust mechanism.  Where do we go from
here?  Let me first deal with two overblown statements:

On Fri, 28 Jul 1995 10:32:24 -0800 (PDT), Bill Yeager wrote:
> We solved the problem in a very straight forward way. I removed the rexec
> auto login code from the c-client.

This does eliminate hanging on rsh, although the main program can just as
easily control the string sent to c-client.  It never ceases to amaze me that
people seem to think that c-client argument strings are immutable parts of
their user interface.

But then we read:

> Too big of a security risk. Someone walks into my office, starts up Roam and
> is reading my mail. We always require passwords. And, are looking forward to
> SKEY.

Say what?!!!

The ONLY security risk that is excised by removing the rsh code from c-client
is the elimination of an invocation of a possible Trojan horse version of rsh.
And if your rsh has had a Trojan inserted, you have considerably more problems
than worrying about someone walking into your office.

The same fellow who walks into your office to start up Roam and read your mail
can also do shell commands including rsh to the server host.  Whether or not
he succeeds depends upons whether or not you let him rsh to the server host.
And if you don't let him rsh to the server host, then it doesn't matter
whether or not Roam tries to rsh to the server host.

In other words, some or all of the following measures are appropriate to
achieve a site policy of "always require a password":
	1) remove/disable ~/.rhosts on the server machine
	2) remove/disable /etc/hosts.config on the server machine
	3) remove rshd entry from /etc/inetd.conf on the server machine
	4) delete rshd, rlogind, etc. binary on the server machine
	5) delete rsh, rlogin, etc. binary on the client machine

Let me emphasize that as long as you have rsh and rlogin binaries on the
client machine, you have that potential security problem.  The presence or
absence of code to attempt "rsh <server> /etc/rimapd" in c-client does NOT
affect your security one way or another.  Removing the rsh binary on the
client works just as well as removing the code in c-client, AND it closes the
holes.  rsh is a setuid program.  c-client programs are not.

If you failed to take the measures noted above, then you are deluding yourself
in thinking that you accomplished anything.  Actually, if your policy really
is "always require a password", then nothing short of doing ALL of 1-5 above
will satisfy that policy.

On Fri, 28 Jul 1995 15:52:58 -0400 (EDT), John Gardiner Myers wrote:
> That's just the tip of the iceberg, risk-wise.  Someone gets one of
> the IP-address-spoofing scripts floating around on IRC or whatever,
> runs it, and is walking all over your server machine.

This is an argument against using IP addresses for authentication and
filtering -- to wit, that the entire r????? series of protocols are a bad
idea.  It isn't as if this wasn't known a decade again; I remember long
arguments with UNIXoids about this and their bashing TOPS-20 because we
wouldn't implement the r????? protocols.

Be that as it may, this is the situation on every UNIX system on the Internet.
For better or worse, we have to live with the consequences of the decision to
deploy NFS and r????? software on virtually every system on the entire
Internet.

> It's safe to say that sites would not be significantly increasing
> their exposure by modifying their IMAP server to always accept the
> null string as a password.

John, this is utter nonsense and you know it.  Shame on you.  If we were
commercial you'd be accused of spreading FUD against a competitor.  Why don't
you say (with equal accuracy):
	It's safe to say that sites would not be significantly increasing
	their exposure by modifying their UNIX system to always accept the
	null string as a password.

In order to have the risk at all, an administrative decision must be made to
deploy the rimapd capability.  The /etc/rimapd link must be installed, and
r????? access must be granted by the server to the client.  Furthermore, the
server must NOT deploy defenses against IP spoofing, and must NOT establish
restrictions on rsh access to the server (e.g. an imapd-only shell).

NFS is orders of magnitude more dangerous than rimapd.  It is vulnerable to
everything that rimapd is, and more; and furthermore has much greater
consequences on a penetration.  Yet in spite of all of this, we don't hear the
same level of fear-mongering about NFS.  NFS is too useful for sites to give
up.

> It's one thing that Pine/c-client ships with a loaded gun pointing at
> the site administrator's foot, with a sign on the trigger saying "pull
> this, it's convenient!".  People do stuff like that all the time.

You can also say:
	It's one thing that UNIX ships with a loaded gun pointing at
	the site administrator's foot, with a sign on the trigger saying "pull
	this, it's convenient!".  People do stuff like that all the time.

For better or worse, this is the world in which we live.  It is unfair of you
to bash c-client for using a heavily-advertise and universally deployed aspect
of UNIX, just because that particular aspect has risks.  Risk is something
that we have to deal with in all facets of life; it is impossible to be free
of all risk.

What is needed is the understanding to establish appropriate risk management,
NOT fear-mongering.  Utility needs to be balanced against risk, and risk needs
to be minimized as much as possible.

> What I find truly annoying is the amount of difficulty and pain this
> facility causes people who don't want to use it.  ":143" indeed.

Take up the question of ":143" with the user agent developer.  It is no big
deal for a user agent to take care of this.  There is no law that says "thou
shalt present the exact c-client specification string to the user, and thou
shalt require same."

> This
> facility should require specific action to enable, not to disable.

There are (at least) tens of thousands of users of the rimapd facility,
including the overwhelming majority of IMAP users at UW (tens of thousands at
UW alone).  Put crudely, someone's ox is going to get gored no matter what
action is taken.

Any action c-client takes to enable or disable rimapd is irrelevant to what
Pine or other UAs do to enable or disable it, other than to make more work for
the UA developer.  The UA developer must decide what the UA's action should
be.  If c-client changes now, this means that every UA now has to deal with an
unstable base platform depending upon which version of c-client is used to
build the UA.  The UA has the decision ripped from its hands.

WHERE DO WE GO FROM HERE?

Quite frankly, measures such as Kerberos, S/Key, etc. have not been deployed
to near the extent o the r?????? protocols.  Similarly, secure remote
filesystems have not been deployed to near the extent of NFS.

What this means is that we have to live with them now, and for the forseeable
future.  We are not going to make r?????? and NFS go away any time soon.  We
have to secure them from the IP spoofing attacks, and any future attacks which
they will be vulnerable to.  Until such time as satisfactory and universally
deployed alternatives exist, we will be stuck with them.

It is NOT helpful to complain about the presence of the rimapd facility, just
as it is not helpful to complain about NFS.  For the time being, these are
needed.  If we didn't have it, we'd have more passwords transmitted in the
clear AND WE WOULD HAVE PASSWORDS STORED IN THE CLEAR ON CLIENTS.

Let me restate this: WE WOULD HAVE PASSWORDS STORED IN THE CLEAR ON CLIENTS.
There is a large user community which rejects having to type a password just
to read their mail, after they have already typed a password to get access.

This is particularly the case on UNIX-based clients.  You can BS the users of
DOS and Mac clients (but I've noticed a lot of these storing passwords in the
plain on the local disk).  Users of UNIX clients are less agreeable.  They
WILL choose clients which do not force them to issue passwords, and there WILL
be vendors who provide them with such clients.

A simple investigation in what's available in the POP world demonstrates this.
Suppose we clique together and say "none of us will do it."  Then, you'll get
the trade rags saying "IMAP has some neat features, but it forces you to type
your password all the time.  POP doesn't, so you should buy POP instead."

This is, unfortunately, what we have to deal with.

Personally, I would much rather press forward with developing new technologies
that eventually will allow us to abandon rimapd, NFS, and similar inherantly
unsafe technologies.  I see bashing on rimapd as a distraction from this goal.

Kerberos, S/Key, etc. are *NOT* here now.  They are available to a subset of
the available systems.  There may or may not be significant development time
and expense involved in deploying these tools.  I manage seven UNIX systems,
and NONE of them has Kerberos or S/Key available on a plug'n'play basis.

I suggest that we roll up our sleeves and get on with fixing this, rather than
bicker about the wisdom of using the existing tools or the band-aids holding
them together.  Nobody would be happier than me to see rimapd expire.

---

From: Simon Spero <[email-masked]>
Date: Fri, 28 Jul 1995 22:00:37 -0700 (PDT)

There is another problem with the rsh hack that probably only affects one 
person (me). I'm running cyrus imapd, and normally access it from unix 
systems via pine. tipper, being a good southern girl, very rarely goes 
down. However it NFS mounts several file systems on less well behaved 
systems that cause rsh's to get wedged. When I set up cyrus, I was 
careful to elimnate dependencies on these Non File Systems, so even if 
nothing else works, imap is still good. I was having great fun trying to 
work out why things were breaking when the null MTA ('telnet tipper 143') 
was working fine. 

BTW, I can sort of see the reasoning behind the retry loop around the 
connection-rejected message. At the time the code was written, the usual 
cause of that message was for a system to be part way through booting- 
(remember, unix doesn't even boot fast anymore). Since all computers are 
unix computers, and everybody runs the r* protocols, that's the only 
possible cause of the error.

Simon

---

From: John Gardiner Myers <[email-masked]>
Date: Mon, 31 Jul 1995 17:10:47 -0400 (EDT)

While the rsh mechanism is indeed specific to the c-client
implementation, the interoperability problem (slow or hanging
connections) does tend to affect the entire IMAP community.

It apparently wasn't clear in my last message that I'm not criticizing
c-client for using rsh per se.  A lot of people, including every
single unix vendor I know, ship systems with the "loaded gun" known as
rsh.  I personally find that very frustrating, but that's the state of
the world.  Computer security is a very frustrating field.

The problem I have with c-client is that when the rsh service is not
available on the server, users frequently get observably poor IMAP
service.  Granted, the hanging behavior comes from rsh client source
code which c-client has practically no control over, but I do think
the problem needs to be addressed better by c-client.  Possible
solutions (in order of decreasing utility) include:

* Have c-client open a probe connection to port 514 before attempting
to run the rsh command.  Skip running rsh if the connection fails.

* Make the IMAP-over-rsh client feature be runtime enabled/disabled
system-wide.

* Provide a simple "I don't do rsh" server which causes rcmd() to fail
immediately.

On the subject of comparing IP-address-based authentication with
plaintext passwords, if you have protected against someone spoofing an
IP address, you have in all but extreme cases also protected against
them sniffing packets.

-- 
_.John G. Myers		Internet: [email-masked]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up

---

From: Mike Macgirvin <[email-masked]>
Date: Mon, 31 Jul 1995 15:16:01 -0700 (PDT)

Apologies for not letting this thread die a natural death. This will be my last
post on the subject.

>  to run the rsh command.  Skip running rsh if the connection fails.

	This sounds workable if Mark has no major objections. It's more or less
what I was planning to add at the application level. If this isn't plausible
within the c-client, I'll go ahead with it at least for my app and I'd
encourage others to do likewise.

>  * Make the IMAP-over-rsh client feature be runtime enabled/disabled

	The problem here is that I kinda' like the rsh; and it works fine from
the office, but fails from my home slip connection; which collides with a
tcp_wrapper (as it should). Doing this turns it off globally and fails to take
full advantage of the access features we _do_ have installed 
	-- although the home connection is where I'm most vulnerable to
sniffing because it traverses more segments (sigh...). The local systems are
wired to page me whenever somebody turns on promiscuous mode (*). 

>   * Provide a simple "I don't do rsh" server which causes rcmd() to fail

	Harder to get system admins to install; and also has the drawbacks
mentioned for the last item; i.e. global on/off instead of selective.

mike

(*) Don't ya' wish you could do this with the wife? ;-)

---

From: Mark Crispin <[email-masked]>
Date: Mon, 31 Jul 1995 15:27:36 -0700 (PDT)

> connections) does tend to affect the entire IMAP community.

Umm, I'd say a "minority", but a large enough one that it has to be addressed.
Fair enough?

> to run the rsh command.  Skip running rsh if the connection fails.

I thought about this, but there's a few problems:
	1) It doesn't help when rsh attempts are dropped on the floor; it'll
	   still have to timeout.  The only thing you'll gain is that a
	   shorter timeout is possible.  On the other hand, that can cause
	   inconsistant behavior on heavily-loaded systems.  Suppose I time
	   out after 10 seconds, but the system is so heavily loaded today it
	   takes 11 seconds to make the rsh.  The user would be surprised that
	   she is asked for a password.  If she's been properly indoctrinated
	   about system security, she'll immediately call the help desk and
	   report that some crack attempt tried to induce her to divulge her
	   password.

	2) The normal response to a non-privileged process opening a
	   connection on port 514 is to close the connection.  It's not always
	   possible to distinguish that from "connection refused".

	3) A wrapper that logs (but otherwise permits) rsh attempts will
	   record twice as much rsh traffic and in particular will record 50%
	   suspicious "not secure port" (sic) rsh attempts.  People tend to
	   get awfully irate about these things, even when you try to explain
	   why it's happening.  The same guys who say "log everything" then
	   blame you for cluttering up their logs...  ;-)

> * Make the IMAP-over-rsh client feature be runtime enabled/disabled

As Mike pointed out, this is the wrong place to throw such a switch, since it
may be alright with some servers but not with others.

I may be mistaken, but I assume that most UNIX-based IMAP clients are either
running on a member of a cluster that includes the server (in which case rsh
would almost always be enabled) or are running on a personal workstation (in
which case a single-client solution is just as appropriate as a global one).

There is no reason why the UAs can't do this itself, if that is what is
desired.  There is no law that says "the user MUST type the :143", or that the
UA present anything that looks like a c-client string.

> * Provide a simple "I don't do rsh" server which causes rcmd() to fail

Not surprisingly, I think that this is the best solution, but it is more
difficult than that.  This solution won't work well with a TCP wrapper which
selectively denies rsh access depending upon IP address, or at all with a
gateway that filters out rsh connects before it gets to the host.  As sad as
it seems (damn! I wish I could do this!), I don't think this is the answer.

I would be delighted if there was a clear-cut solution.  So far, I haven't
seen anything that either doesn't solve the problem or potentially makes
things worse.

> IP address, you have in all but extreme cases also protected against

I don't understand this claim.  How does protecting against someone spoofing
an IP address protect you "in all but extreme cases" against some random SUN
on your subnet getting cracked?  As far as I understand, the only way to
protect yourself against this is to isolate SUNs (and any other machine which
permits promiscuous mode in its Ethernet hardware) on a separate subnet, and
if possible to have secret booby traps to ring alarm bells when such machines
are cracked.  [The booby traps must be secret and site-specific, since if the
bad guys are aware of their existance they can arrange for counter-measures.]

-- Mark --

---

From: Aladdin Khamis <[email-masked]>
Date: Wed, 2 Aug 1995 12:16:49 +0000 (GMT)

Where can I get the best updated gcc debugger?

			Thanks
			
				Al

---

From: Joel King <[email-masked]>
Date: Tue, 15 Aug 1995 09:43:21 -0600 (MDT)