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

[Greg A. Woods]

[ On Thursday, February 21, 2002 at 18:44:19 (-0800), David A. Desrosiers 
wrote: ]
> Subject: Re: ANN: cvssh - secure ext-to-pserver bridge
>
>         I know how to do anonymous read-only ssh, and it actually involves
> nothing other than SSH itself (well, and sshd). NetBSD's implementation uses
> a wrapper, which.. ta-da, is exploitable, since you can break through it by
> killing the child process during the fork. It's been explained in many tomes
> before, do not fork off children if you intend your application to be
> secure.

I don't personally know if NetBSD's implementation of anonymous SSH
access to their CVS repository is vulnerable or not.  I've not examined
it, nor have I tested it.  I doubt it would be a huge problem even it it
were exploited though -- its users would very quickly notice any
corruption introduced into the repository it hosts and no doubt it would
be corrected before any really long-term costly damage could be done.
Security is not a binary thing you either have or don't have -- it's a
level of risk that you feel comfortable accepting, combined with deeper
understanding of the threats you might face and the defenses you might
erect against thost threats.

However I do know that it will not likely be vulnerable to any kind of
attack like the one you're proposing (unless it's so lamely programmed
that a 10 year old could spot the bugs).

> > Note that regardless of how you provide anonymous read-only access it
> > should undoubtably be done on a separate machine with a separate copy of
> > the repository.  Do not trust mixed anonymous read-only access and
> > commit access to the same files!
> 
>         And how, praytell, do you get those files sync'd back to the main
> repository? Or are you suggesting forking the entire project each time
> there's a commit? Sort of ruins the whole purpose of cvs, doesn't it?

Do you still not understand the meaning of "read-only"!?!?!?!?!?!?

Your question strongly suggests you do not.

If you sync the read-only, anonymously accessed, repository back to the
master, and if there are any changes that happen to be transferred, then
you have just undoutably corrupted your master repository, perhaps even
injected malicious code into it.  A read-only repository is not supposed
to change in any way (except when it might be re-created or updated from
the master repository under authorised control), least of all by the
anonymous users who might access it.

Perhaps I can draw a crude picture for you with ASCII graphics without
wasting too much more of my time:

================                                        --------------
|| secure     ||                                        | dedicated  |
|| SSH-only   ||----> rsync or CVSup, etc. via SSH >--->| anonymous  |
|| CVS server ||                                        | CVS server |
================                                        --------------
      ^                                                       ^
      |                                                       |
       \                                                      |
        \  <-commits                          read-only->    /
         -----------------Big Bad Internet------------------/

Commit access is only to the secure (individual user accounts) SSH-only
server, and read-only anonymous access is to the separate repository
copy on the dedicated (no other services or data) anonymous server.

You don't worry so much about the second server -- if someone trashes it
you just rebuild it and hopefully find and close the vulernability they
exploited so they can't do it again.  You do frequent updates from the
master so even if they corrupt it with a trojan or whatever their hacks
are obliterated with the good code again.  You automatically audit the
updates so you can detect attempts to corrupt the repo, and of course
you monitor and audit all accesses to the anonymous server so that you
can hope to notice stealth attempts to corrupt the repo copy at key
times and then hide the corruption by undoing it just before your update
runs again.  You implement external checks to compare copies of the
repositories retrieved from each server to an undisclosed third location
at random times so that you can spot successfull stealth attacks.  You
warn all authorised committers to watch for discrepancies in, and
unexpected changes to, the code, especially code they're not working on
at the moment.

I know you don't like sourceforge very much (at all), and I'm not sure I
like them all that much either, but trashing the proven mechanisms
they've used to build it, and hoping to do better with the truly
atrocious methods you've proposed, isn't really doing anyone any good.

-- 
                                                                Greg A. Woods

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