On Wed, Oct 20, 2004 at 10:31:38PM +0200, Alex Holst wrote:
> I'm a demanding sort of guy. I want the Subversion project to put more
> effort into the security of its code. I have reasons for this!
>
> I have articulated some of these reasons in a document partly aimed at
> Subversion developers and partly aimed at Subversion users. The part
> aimed at the developers is mostly complete, and I'd like you all to read
> it so we can talk about how to best carry some of these suggestings into
> the project. I think it is badly needed.
>
> Subversion security - http://mongers.org/svnsec
>
> I will continue to work on the document over the coming days.
>
> Looking forward to the discussion.
Frankly, I think your evaluation is largely inaccurate.
"Virtually every security bug found in software either stems from a
design or implementation flaw. Hence, making secure software require
careful adherence to rules about avoiding programming language and OS
pitfalls. Additionally, security code inspection and testing can be used
for increased assurance (not guarantee) that security flaws are not
present. In some situations, a particular approach to software design
can help reduce the exposure, should a flaw sneak past security code
review and testing. The Subversion team do none of these things."
That's simply not true, we most certain do some if not all of those
things.
The biggest problem with C code for example is
buffer overflows, particularly when dealing with strings. We've got
very nice functions for handling strings that handle the issues with
working with strings and avoids a lot of the pitfalls.
People have run security testing audit tools on our source code and
reviewed the places it found to verify if there were issues or not.
As far as surface area of possiblity for attacks. Sure we support
multiple access methods. But the vast majority of users don't run all
of them. In fact the SVN project itself only makes our repository
available via http. The main Apache module is all of 9531 lines.
mod_authz_svn is all of 635 lines. And svnserve is 1974 lines. These
are relatively small amounts of code with clear deliniations between the
access layers and the support code. If you feel that the Apache server
itself is too big of a risk to run then don't use it, use svnserve.
Do we look for potential security issues when reviewing code? I know I
do when I review every commit. I can't speak for everyone else. I
think it's pretty unfair to say that we need to implement "security
review of new code." Everything that gets committed to our repo gets
reviewed by multiple people. Do we miss things, absolutely. But the
same process you praise for ensuring careful attention to maintaining
repository integrity, works to avoid security issues.
The problem with your assessment is that it is based on only part of the
picture. Many discussions regarding the issues you bring up go on via
the security list that you don't have access to or a committers only
list that you also do not have access to. We talk about these matters
here to avoid needlessly exposing our users to problems before we have
solutions or needlessly scaring users about things we realize aren't
really issues.
Can we improve, absolutely. But you're assessment that we do none of
these things is simply inaccurate.
Also you say that 4 out of 9 releases have been for security issues
found by outsiders. That's not true. The last two security releases
have been for issues that have been found by developers. The previous
two were reported to us by other people. Though the issue fixed in
1.0.5 came with almost no analysis other than SVN crashes, we figured
out the security implications of that issue. Additionally, I don't see
how it is relevent who discovers an issue. You make it sound like it's
awful that someone else is finding issues for us.
Ultimately, I think we have a pretty good security history. So far
we've had only 2 vulnerabilities that risked gaining access to the
system. The first one was pretty shallow and should have been caught.
But it happened to be a case of reusing a printf format for a sscanf, so
it didn't stand out even if you read the code.
The other one was a pretty obscure issue. I don't think very many
people would have been able to look at the code and find it.
The other two completely involved permissions on a repository. Which
regretfully is a feature that is rather underdeveloped and IMHO is
implemented in the wrong layer.
I think you're also being a bit unfair to us on the basis that we handle
virtually anything that might be considered a security flaw in someones
installation as just that. For instance consider 1.0.6, it fixed an
error that occurred in a pretty odd configuration.
Also, there is no release that has ever introduced a new vulnerability
that we're aware of at this time. So far everything that's been found
and fixed has been applicable to every version, at least as far back as
the 1.0.0 release. I suppose the mod_authz_svn stuff "introduced" new
bugs when they were added. But only to the degree that they failed to
do as much as they should have. Of course there was nothing to do the
job before the mod_authz_svn was added.
Let's agree on this much. Security problems are going to happen. We
can take every step in the world to try and prevent them, but we'll
still have some. What matters more than anything is how we respond to
them. We've done a good job of that.
If you want to do something rather than writing an assessment of how
we're not doing things right, why don't you make an effort to get
involved in reviewing code? Writing test suite coverage. Don't sit
there high and mighty saying we're doing a poor job. Do something.
This is a project where you can do pretty much anything you set your
mind on doing. I think we'd all much rather have your involvement than
a rant.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 23:29:06 2004