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.
---------------------------------------------------------------------
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:35:04 2006