info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANN: cvssh - secure ext-to-pserver bridge


From: Greg A. Woods
Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
Date: Fri, 22 Feb 2002 16:48:57 -0500 (EST)

[ On Friday, February 22, 2002 at 05:46:34 (-0800), David A. Desrosiers wrote: ]
> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>
> > You must only sync it in the other direction -- i.e. update the
> > read-only server _from_ the master!
> 
>       Great, then once again, you make absolutely no sense.
> 
>       If I have a copy of the master, which allows anonymous read-only
> access, and that copy also accepts authenticated commits (via whatever

What don't you understand about "read-only anonymous access"?  Where in
that phrase does it say anything about allowing commits?!?!?!?!  It
doesn't.  In fact it says exactly the opposite!

Remember my original assertion:

cvspserver is secure enough for exactly one and only one purpose:
read-only anonymous access (and even then it's wide open to MITM
attacks, many spoofing attacks, loss of integrity, and so on)

That means no other access of any kind.  Nothing whatsoever.  Nothing at
all.  No commits, no tags, no changes, no write access of any kind.  The
pserver user-ID specified in /etc/inetd.conf is a totally unprivileged
user (i.e. one that owns no files, has write access only to
world-writable files and directories, of which there should be almost
none of course)

Now PLEASE try to read what I actually write and not go between the
sentences like you've been doing since day one here.

> > Sorry, but if you want any security for commit access whatsoever then
> > you MUST assign unique individual system accounts to every authorised
> > user.
> 
>       This is not security. Repeat that slowly to yourself.

It sure as hell is!  Security MUST include accountability,
authentication (which includes identification), and authorisation.

In the networked world security also requires strong crypto.  You can't
even get minimum security for the least important, least threatened
networked security unless you use strong crypto to make the connection.
Note too you can't make effective use strong crypto without strong
authentication either.  Almost every SSL web site in the world either
relies on external security measures (eg. credit card companies,
carefully contrived external references and consistency checks, etc.) or
is not secure in any way whatsoever and even worse is giving a false
sense of security.

Please READ Schneier's "Secrets & Lies" cover to cover (again if you
think you've already read it) before you respond.

> If I give
> thousands of local unix-based accounts on machines to developers in Germany,
> Sweden, Australia, Singapore, etc. to developers who have projects on the
> server.. developers I've never met in person (nor probably never will meet
> in person), how can I be sure they are the _ONLY_ person that uses their
> computer? How can I be sure _THEY_ know how to secure their password,
> network, credentials, directory permissions, keys? The answer is that you
> can't be.

Hah!  So you've got a quandry don't you.  You want security, but you
don't seem to know how to enforce it.

Well, perhaps you should learn something about real-world security and
how it works outside of the very controlled world of a computer program.

You can't have computing security by building a secure computer system
alone.  Such security is useless unless maybe that computer is encased
in about 10-foot thick re-inforced concrete and dumped to the bottom of
the deepest trench in the ocean.

>       If you can't control remote access, you must control it locally.

Now you're really off the deep end.  You're not making any sense at all.

You're obviously not learning anything here.  Please go learn more about
real security and don't come back until you think you have.

> > That's pure and simple BS.  Sourceforge uses only SSH and they have tens
> > of thousands of users, if not hundreds of thousands.  Certainly it
> > scales.
> 
>       Funny, they've also got it wrong, and have been hacked 6 times
> _BECAUSE_ they use ssh.

Nope, you've got that wrong too.  They were hacked into and the hackers
used trojaned SSH programs to spread the hacks.  SSH was not the
vulnerability here -- just the way a very few users used it.  I too
tried to tell the SourceForge folks that there were some flaws in their
policies and implementation, but I still encouraged them to use SSH, and
I still recommend SSH as the only really viable tool to use, and I'll
bet they continue using it as successfully as it is possible to use it.


>       It's _EXACTLY_ the SourceForge implementation I'm avoiding.

You'll be exploited in seconds if you use cvspserver for anything any
group of crackers want access to.  It has zero security.  None
whatsoever.  Good luck next time, so sad, sorry you lost.

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]