[ On Thursday, August 10, 2000 at 22:09:44 (-0400), Justin Wells wrote: ]
> Subject: Re: cvs-nserver and latest CVS advisory
>
> Yes I have. That's what I just did.
No you did not -- you showed some completely unrelated claims and then
switched the bait....
> > Indeed if your server contains only your repository, and especially if
> > you've stripped it of unecessary tools, the only real risk is directly
> > with your repository itself -- i.e. right where you propose to lock
> > people in.
>
> Think please.
Excuse me? Please do some thinking of your own for a change!
> They have nothing to attack in there, so they don't break root. Since
> they don't break root:
They don't need to break root -- they've already got write access to
your one object of value!
> > Unfortunately with cvspserver you've no accountability because now any
> > authorised "user" will be able to use any of the many available hacks to
> > compromise the identity of any other "user" and then even blatantly
> > spoof changes as that other user.
>
> They can't do this. Any change will be done under their own uid, and
> since they can't break root, they can't change their uid.
Pulleeeeze! There is NO security in cvspserver! Any user can spoof any
other user with only a very few "script-kiddie" class tools! Any third
party can relatively quickly and easily spoof anyone too! Even worse
it's not hard to spoof the server from the client's point of view too!
I.e. there's zero accountability in cvspserver and without
accountability you can throw all the other buzzwords you want around and
you still have no security whatsoever.
I thought Noel did a very good job of explaining this issue to you and
you've either ignored him or completely failed to integrate it into your
understanding.
Besides, nobody *needs* root access to crack a cvspserver system -- it's
just that cvspserver, especially your hacked version with chroot() in
it, requires that it be run as root and thus this only makes it more
vulnerable -- i.e. you've taken an insecure C/S system and made it even
less secure by introducing yet another unnecessary risk!
There is no excuse for not using SSH!
> The bigger it becomes the more people there will be reading the diffs
> and the more difficult it will become to install covert changes. Duh.
Read a little history please.... It's already been done in more than
one place!!!
Also, remember what I said about spoofing the server? Well what if
you've made the mistake of using the server in the same way as other
clients to view code changes and do your audits? Can you guess why the
cracker will want to spoof the server? If you're not extremely careful
you won't see anything that they don't want you to see!
> > Furthermore since you're proposing not just an anonymous read-only
> > server, but instead a full-fledged repository with commit access, you've
> > complicated your chroot configuration by at least an order of magnitude,
> > and maybe more if your users demand fancy CVSROOT/*info hooks.
>
> They don't get write permission to CVSROOT/*info files.
hmmm... i wonder what i can do when a privileged program runs an
un-patched version of *BSD Mail.... now where did i put that suidperl
exploit anyway -- it had the exact recipie i need! yes, there it is!
give me a shell NOW you broken *info script!
I.e. I don't need write permission to any of the files in CVSROOT, nor
to any of the scripts and programs they call in order to view them as a
major vulnerability.....
> Give me a general shell on your machine and I'll break root within a
> month or so. I'll just race you every time an exploit is posted on
> bugtraq or rootshell.org--you have to win every race, I only have
> to win once.
No, you won't. You'll only get an account if you explicitly promise
*not* to try anything unauthorised. Of course I'm going to force you to
use SSH so that you can't claim you're not responsible, and I'm going to
further warn you that if your SSH client is compromised and is the true
source of any damage then it's still be you who's ultimatley directly
responsible.
So, if you do mess about then I'll probably catch you at your tricks and
hold you accountable for your promise of never trying to break root!
And in the hypothetical scenario where you work for me you'll be
immediately dismissed and walked out the door by the security guard,
never to return again.
If you do break root and leave any evidence behind whatsoever (and
unless you break all my systems, including the secure log host, it'll be
impossible for you erase all the evidence), then because I'd explicitly
warned you against even trying I'd be able to bring criminal charges
against you as well as dismissing you should my trust in you been based
on an contract from which you benefitted. This is what accountability
really means! It is what gives your policy real *TEETH*! Even if
you've given me false ID and wormed your way into a position of trust
like an undercover spy I'll still have the evidence and if I'm smart I
may have wormed out of you enough information to make you feel the pain
regardless of whether I can get you with the long arm of the law.
I.e. if you win once your victory will be very bittersweet!
> By locking the attacker in the repository I deny them the chance to
> upgrade theis uid to the root user. Since they can't become root they
> are only able to modify the files that they have permission to modify.
You've said yourself that the system itself doesn't matter much to you.
That means the only thing that can matter to you is your repository
itself. I.e. as has been explained to you several times now, they don't
need to break root to cause you grief beyond your measure!
> > that but with the SSH solution you still have the opportunity to use
> > chroot, and without even the risk of ever running CVS as root!
>
> Yes, and to have ANY security at all you *have* to chroot and you
> have to use real unix userids. That's true for the ssh solution just
> as much as it's true for the pserver.
Huh? that's totally meaningless. have you forgotten how cvspserver
works again? it doesn't authenticate and authorise real unix users --
it's concept of user-ids is completly orthogonal to system user-ids!
(it doesn't have to be by design if the implementation were fixed, but
if it you fix it then there's no point to it in the first place because
then you've only re-invented rsh, poorly....)
> > Yes you still do have to find some basis in the real world for the trust
> > you grant to your developers, and with SSH you have to ensure they
> > understand that your security policy requires that they keep their
> > client machines secure too.
>
> That sounds like a huge barrier to development, and a barrier that I
> don't need to erect given that I can recover from a breach so easily.
Yup, gotta get things done! Life goes on! -- or not. Proper treatment
and handling of animal and human waste is a huge barrier to economic
development, but without it people quickly end up sick and dead. Life's
a barrel of fun until someone gets poked in the eye! Etc., etc., etc.
Have you forgotten already the real-world experience I tried to convey
to you about gaining the respect of your colleagues? With the right
attitude you'll be fostering development, not creating barriers to it.
"Open source development" doesn't mean zero-trust. In fact it means
very much the opposite. Trust must be earned since it can't be bought
when there's no employment contract with security policy teeth in it!
In a volunteer environment trust can come from respect, but if your
developers don't respect you then you probably won't be able trust them
anywhere nearly as much as you could if they did respect you. That said
I can again assure you that if you do not implement serious security on
the repository they use at least some developers will definitely not
trust you!
If you can't trust the developers you "hire" enough to be reasonably
sure they won't mess about with a shell account on your central
repository machine then you really shouldn't trust them to write code
for you, regardless of whether you audit it carefuly or not!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
