On 7/18/06, gmu 2k6 <gmu2006@gmail.com> wrote:
> On 7/18/06, Paul J R <me@pjr.cc> wrote:
> >
> >
> >
> >
> > I've worked on two projects in the last 6 months where svn has been put
> > forward as an "option" and both times its been passed over in favor of
> > things like rational.
> >
> >
> >
> > Fair enough, its been big corporates that I've been working for who value
> > the perceived security they get with products like rational, but both times
> > the same thing has happened. The project goes to get security approval for
> > the various options they have on the table and svn is thrown out by the
> > corporate security groups as an option. Both times, svnserve wasn't even
> > considered to be something that was going to be used, but both times the
> > same argument was thrown in:
> >
> >
> >
> > "well, if the guys who code subversion are willing to have passwords kept on
> > the OS in plain text, how many other problems exist in their code?"
> >
> >
> >
> > To which there is no real answer.
> >
> >
> >
> > The sad fact is that the minimum security level is always one-way hash or
> > two factor auth'ing in those environments. I asked one of the guys to send
> > me an email about why this all comes about and his response was mostly what
> > I expected but he had a few points I hadn't thought of (im paraphrasing
> > here):
> >
> >
> >
> > -----
> >
> >
> >
> > We consider nothing secure (OS, software, hardware, all of it), no matter
> > how up-to-date anything is and no matter how isolated it is from the any
> > other network the potential for someone to "break in" exists (that's the
> > basis from which we work). Keeping plain text passwords anywhere on a system
> > is essentially "giving them away for free", and any hacker that managed to
> > get that close will see the svnserve port open and it's a red-flag for them
> > "hey, free passwords here". Now assuming they managed to hack into the box
> > (and they may not even have to do that), theres no telling what those
> > passwords give them access to. Obviously a certain amount of intelligence
> > will tell you that "a password policy is in order", unfortunately policy is
> > never a real answer to anything. No matter what you tell the users to do,
> > they almost always end up ignoring it cause its "too much hassle" unless you
> > can enforce it, and that's something else svnserve cant realistically do.
> > Even worse, if we implemented some way of checking what the user selected as
> > a password as not being a password they're using anywhere else, and they did
> > the damage has already been done. The password is now in the OS file system
> > somewhere, so what do you do? DOD erase the entire drive? Disable their
> > account across every environment we find they're using the same one? That's
> > an extreme amount of work considering the number of environments potentially
> > impacted, not to mention the waste of the person who now has to call a
> > helpdesk somewhere and sort the situation out (even if it was their own
> > stupidity in the first place). I also said they may not have to break into
> > the OS to get the passwords, which is the second problem with it; What if
> > someone found a hack (buffer overflow, remote execution flaw, etc) in the
> > daemon that allowed the user to just dump the password file from remote?
> > That's an even more troubling scenario.
> >
> >
> >
> > Now with your project, you weren't going to use svnserve, and instead were
> > heading for webdav option. Considering the code that drives svn's webdav is
> > probably written by the same people who would put plain text passwords on
> > the OS, the same level of trust has to be assumed. Unfortunately that's
> > quite low, any developer who considers keeping plain text passwords on the
> > file system of the OS and relying on the OS's own security for protecting it
> > is living in a dream world. I can even bet you money that the daemon doesn't
> > even go to any lengths to protect that file (i.e. doesn't even complain if
> > the file is world-readable). Now if they had just made the file encrypted on
> > disk and force you to enter a password to start the svn server daemon to
> > unecrypt the file (like the way apache keeps its keys), then that's 100
> > times better (not perfect mind you because if you can make the daemon dump
> > its memory in some way you would probably still get the passwords, but at
> > least it's a level of security that is acceptable).
> >
> >
> >
> > Now obviously there's a lot of software out there we use that has exactly
> > the same problems (for example with apache you can keep the key on-disk
> > unencrypted), but none of the products we use give you the potential to gain
> > a real-user password like a corporate lan login. But this is also why we go
> > through each project on a case by case basis. Considering the people who
> > would be using subversion in this environment are fairly "trusted" users who
> > have access to some very sensitive customer information, the risk is quite
> > large. User logins in most environments always have the largest potential
> > for causing damage and we do as much as we can to mitigate the risk. Sadly,
> > the users themselves are usually the biggest problem but we're not in the
> > business of adding to that risk even in the smallest possible way.
> >
> >
> >
> > Using subversion may save you a lot of money (compared to the many dollars
> > you'll spend implementing rational), the project code base may even be quite
> > small and the code itself may be of no value to a hacker (in fact,
> > everything on the server running subversion may not help a potential hacker
> > or be of the slightest use to them). The reality of the situation is I have
> > to ask the question "what else could a hacker gain access to if they got
> > access to that password?" (irrelavent in your environment I know) but then I
> > have to ask "how can we trust code that would allow it in the first place?",
> > and the answer is you cant. We would be negligent to sign off on any project
> > using subversion for just those reasons.
> >
> >
> >
> > -----
> >
> >
> >
> > The way I read all that is simply to say that because subversion's daemon
> > allows this kind of behavior its sadly devalues everything that subversion
> > is. Sure it's a big corporate that can afford a commercial product, but its
> > sad to see svn pushed aside from such a small issue really.
>
> SASL support is being worked on, this will fix the issue. it doesn't
> seem to landing in the 1.3.x or 1.4 branch too soon from what I've got
> as replies though.
> I won't go into the trustworthy code discussion, which is better saved
> for a place far away from my reality. you are free to fuzz svnserve,
> mod_dav_svn, svn+ssh, do static analysis and see what you can find.
> Subversion makes use of APR and Neon. APR is widely used in Apache.
> you will always have the low-level security defects in software
> written in languages where you are responsible for resource management
> at a pretty basic level. using Java or Python (Mercurial SCM as an
> example) gets rid of the simple errors but it's still not safe by
> proof.
> 1) if you want someone to blame if it breaks go with commercial
> software (nevermind I'm also bein paid to work on closed-source
> softwarte)
> 2) if you think this one defect makes the whole project unsecure,
> think about implementing JavaScript, Java, ActiveX filters on all
> users' machines.
I hope this didn't sound harsh, but I just wanted to re-state what
other told me about the issue: it is being worked on and will be
released when it's ready and working (IIRC it's a SOC project active
right now).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jul 18 15:37:33 2006