It's been a relatively long standing policy of the project to not
generate security advisories for low risk denial of service attacks.
I've seen several rationales used over the time for these. Most
notably:
* You need commit access to the repository.
* There are easier ways to DoS Subversion.
I think we should produce advisories for all vulnerabilities in
Subversion. Subversion is used in a variety of configurations and is
almost certainly being used in ways we can not predict. These
configurations make it unreasonable for us to be able to access the
risk that a vulnerability poses to a given installation. We shouldn't
support just the majority of our users but rather should support all
of our users. We support fully anonymous commits, even though most of
users do not use this functionality. If we are going to support a
method of operation, part of supporting that means producing security
advisories to the risks of using that method of operation..
Part of the logic surrounding this policy has been the idea that we do
not want to alarm users by security advisories that do not generally
apply to them. I think some things have changed over the last 10
years since we started this policy. Security vulnerability advisories
are no longer rare or uncommon, I see one virtually every day, many of
which do not apply to me and my configuration. The security community
has gotten better at communicating risk too. There are now systems
like CVSSv2[1] that can be used to communicate the level of risk to
the majority of the users. Users have become more aware that the
number of advisories does not translate into actual risk.
The argument that there are easier ways to DoS Subversion is rooted in
the idea that commit access translates into some degree of use of
resources on the server. E.G. If I can commit enough data to the
repository then the repository will run out of disk space and this
will deny the ability to commit to other users. These sorts of risks
are inherent in operating a Subversion server and should be obvious to
most administrators. We should not avoid pointing out vulnerabilities
simply because we have inherent risks. If there are flaws that
shouldn't be inherent but are easier to exercise than the flaw we are
considering, then we should endeavor to fix those flaws as well rather
than avoiding advising our users of the vulnerability we have solved.
Nearly 3 years ago cmpilato and other developers stated that our
vision as a project was to be "Enterprise-class centralized version
control for the masses." [2] It is my view that part of being
enterprise-class is providing advisories for all your vulnerabilities.
I believe a new approach is called for from the project regarding
security advisories.
1) Begin producing advisories for all vulnerabilities, even low risk
denial of service attacks that in most configurations require commit
access.
2) Begin calculating the base CVSSv2 score and vector and including
them in our advisories. CVSSv2 is designed around considering the
most common configurations, which means our scores would be based
around the assumption that commit access requires authentication.
3) Release low risk and low impact vulnerabilities as part of normal
releases. High risk and/or high impact vulnerabilities can still be
handled via emergency releases.
4) Educate our users on these changes and on how to understand the risks.
Our advisories already do a good job of communicating risk. I really
don't think our users will be alarmed by this, especially if we make
some effort to explain the change to them and educate them.
[1] http://www.first.org/cvss/cvss-guide.html
[2] http://svn.haxx.se/dev/archive-2010-04/0047.shtml
Received on 2013-03-18 23:08:35 CET