Re: FAQ-O-Matic pserver protocol

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guus Leeuw jr. <address@hidden> writes:

> > > Hence I am looking at the pserver protocol, so I figured, it is a FAQ.
> > > Now depending how you interpret FAQ (asked or answered), I was right ;)
> > >
> > > It's apparently asked often, but
> > > https://ccvs.cvshome.org/fom//cache/446.html gives no answer :(
> > 
> > Search the info-cvs archives and you might have more luck. The short
> > answer is don't use it. Move along, this is not the protocol you are
> > looking for...
> 
> The "hence" above was indicating that I am writing a passwd command for the
> pserver stuff, as Jim suggested would be a nice feature...
> On dev, so far, no hard statement against doing this...
> If you think, I shouldn't be doing this, please state so, and I'll back out
> doing more important stuff...

Larry and Derek would both need to agree with me that pserver needs to
be killed before we could rip things out of the feature version. I doubt
that will happen given how many folks still use pserver out there.

There is also a CVSNT fork of CVS that has even more ways to
'authenticate' the client for server operations... they also have the
command you are talking about writing.

Have you considered moving to the CVSNT fork of CVS? (Yes, it runs on
boxes other than Windows.)

> > > Can anybody tell me where the doc is? Can't seem to find it in the
> > > cvs1-12-11 branch...
> > 
> > For HTML Cederqvist manual for cvs 1.12.11, look here:
> > https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs.html
> > 
> > For the client/server protocol, look here:
> > https://ccvs.cvshome.org/source/browse/ccvs/doc/cvsclient.texi
> > 
> > You should be able to find a doc/cvsclient.info file and a
> > doc/cvsclient.ps -- these forms of the document describe both the
> > pserver framework and protocol (as well as the kserver and server
> > protocols). If you plan to read the document closely and you actually
> > care about security, issue ear-plugs to your neighbors so that your
> > screams will not distrub them too much.
> 
> OK, thanks ;)

You are welcome.

> > In general, my personal opinion is that the pserver and kserver
> > protocols should be removed from the cvs sources completely. It is never
> > secure to run the cvs executable as root which is required to use the
> > pserver protocol. The cvs sources were never designed with security in
> > mind and running them as root is idiocy. (Just say no.)
> 
> You're kidding right? Root is a good user(TM), no?

Actually, no, I am not kidding.

Root has too much power to run an untrusted application that has been in
the past and likely will be again in the future subverted into letting
an external agent execute undesired operations as root on the server
machine.

If you look at the main page (https://www.cvshome.org/) you will see
that even cvshome.org was subject to an attack on a cvs security
violation.

If cvs runs as root and allows connections on port 2401, then it had
better be very well audited and have a very tighly written security
model for dealing with all of its inputs and avoid all possibility of a
privilege escallation that results in abuses to that connection.

There is too much #ifdef'd code and hard to semantically verify code in
the current pserver code path for any sane security expert to give
anything better than an 'unsecure' rating to it.

One way to deal with this problem would be to do something like OpenSSH
does with priviledge separation, so that only a tiny fraction of well
tested and closely examined code will ever run as root and that it
carefully performs its authentication checks and validations. Further,
it would not provide for a password that is only obscured on the wire,
but is otherwise transmitted in the clear for use in any kind of replay
attack you wish to imagine.

The only time it might make sense to have a "pserver" server running
would be in a read-only mirror replica of an existing repository on a
machine that may be re-installed on a moments notice WHEN (not if) it is
found to have been compromised. If said read-only mirror was providing
'anonymous' checkouts, then that might be a useful case for "pserver"
mode to exist (I would still rather see anonymous ssh transport for 
such purposes.)

> > If you are using pserver, I hope it is on an isolated LAN with lots of
> > firewalls and does not control any sources you really need to be kept
> > secure. I also hope that you are making plans to transition away from
> > pserver usage as fast as possible.
> 
> I use it since a couple of years on a LAN that has merely an ADSL router
> listening, and a linux based firewall blocking... in between the LAN and the
> server is still an SMC Barricade allowing nothing from the outside to create
> a network session... Guess this is triple secure... I get a lot of probes,
> but they don't make it through the server... So that should be cool...

That might make it a bit more difficult and the 'bad guys' may go
looking for easier pray.

> > Summary: Friends don't let friends deploy cvs pserver configurations...
> 
> Sure enough... What about the people that do use pserver, and want their
> users to change their passwords from CVSROOT/passwd? 

If they are going to move to cvs 1.12.x, then the could go ever further
down the road to perditions flame and use PAM authentication and change
their password via a NIS protocol if they want.

> No change today... Not securely, that is. 

Hmmm... that really is very funny. Sending the password in a completely
reversible encoding otherwise in the clear to do normal operations is
secure?

> So we might consider implementing it, no? 

I can't stop you.

> Simply sending a scrambled password over the *LAN* can't hurt too
> much... For WAN, pserver is quite different ;)

Well, the distance from a LAN to a WAN is a lot smaller than you might
believe.

How many botnets are running on your internal network today? How certain
are you that the next virus that attacks a machine inside of your
current firewall won't be used to attack your CVS server to send copies
of proprietary source files or documents to a third party? (Leaving
aside that if they own the client they can already send copies of all of
the files that are currently checked out, of course).

Such programs could possibly just read and forward a .cvspass file
contents laying around from some user and so get a bit further into the
protocol than the first few auth exchanges.

> Anyways... Development stopped until verdict is received ;)

CVS is open source. There is nothing to say that you might not provide
whatever patches you want to them and make them available to whoever
wants them.

That said, if you really are planning to cleanup pserver to make it
'secure' for changing a password, maybe you can find the time to do a
more secure replacement code base for the pserver implementation
instead? If you can get security folks to go thru all possible code
paths and shake out the next big bug (and fix it), then I am sure
a lot of folks would appreciate your work.

A strong believer in 'cvs password' should go and look at what CVSNT
does. They already implement a 'cvs password' command. The protocol
element they added is "passwd" so if you use that token in any code you
submit to the CVS version from cvshome.org, then you MUST follow their
protocol exchange rather than implement your own for CVS). We have tried
very hard to ensure that nothing they add or we add will break the basic
compatibility of a mixed client/server with CVSNT and CVS acting as
either role.

You will want a copy of the cvsnt sources. It may be fetched here:

  cvs -d :pserver:address@hidden:/usr/local/cvs co cvsnt

you would need to look at the cvsnt/src/passwd.c sources for their
implementation. The cvsnt/doc/cvsclient.texi file has their
documentation for the 'passwd' command protocol.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCDyO63x41pRYZE/gRAqlYAKDl8LiKd2IF92hwQf8qkr7UWe+NFACePnxY
xoF4dLbNhYz4tku4lXp1cWQ=
=0fTH
-----END PGP SIGNATURE-----