subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1003583 - in /subversion/site/publish/security: CVE-2010-3313-advisory.txt index.html
Date Fri, 01 Oct 2010 16:50:59 GMT
Author: hwright
Date: Fri Oct  1 16:50:59 2010
New Revision: 1003583

Add advisory for CVE-2010-3313.

Patch by: cmpilato

* publish/security/CVE-2010-3313-advisory.txt:

* publish/security/index.html:
  List the new CVE (and a couple of whitespace fixes).

    subversion/site/publish/security/CVE-2010-3313-advisory.txt   (with props)

Added: subversion/site/publish/security/CVE-2010-3313-advisory.txt
--- subversion/site/publish/security/CVE-2010-3313-advisory.txt (added)
+++ subversion/site/publish/security/CVE-2010-3313-advisory.txt Fri Oct  1 16:50:59 2010
@@ -0,0 +1,193 @@
+  Subversion servers up to 1.6.12 (inclusive) making use of the
+  "SVNPathAuthz short_circuit" mod_dav_svn configuration setting have
+  a bug which may allow users to write and/or read portions of the
+  repository to which they are not intended to have access.
+  Subversion's WebDAV server module, mod_dav_svn, can interact with
+  the Apache HTTP Server and related modules in a variety of ways to
+  implement various authentication and authorization policies for
+  Subversion repositories hosted via that service.  One such way
+  involves setting the value of the mod_dav_svn configuration
+  directive SVNPathAuthz to "short_circuit", a non-default value which
+  causes mod_dav_svn to bypass Apache's internal authorization
+  subsystem and to instead query Subversion's built-in authorization
+  logic directly.  Unfortunately, a bug in the implementation of this
+  feature (which exists for the purpose of improving the performance
+  of Subversion's authorization checks) causes it to ignore access
+  rules which are scope-limited to named repositories.  Depending on
+  the configuration of the access file which Subversion consults to
+  determine the repository's access policy, this can have the effect
+  of inadvertently exposing more (or less) information to a user than
+  intended.
+Known vulnerable:
+  Subversion servers 1.5.0 through 1.5.7 (inclusive)
+  Subversion servers 1.6.0 through 1.6.12 (inclusive)
+Known fixed:
+  Subversion 1.6.13
+  Subversion 1.5.8
+  Assume that there exists an Apache-hosted Subversion service,
+  configured to require valid authentication of all users, and
+  employing the following access configuration file for the purpose of
+  authorizing access to specific portions of hosted repositories:
+     # All users have read permission on all repositories in their
+     # entirety unless otherwise noted.
+     [/]
+     * = r
+     # Hide the '/pokernight' directory of the 'office' repository
+     # from the Boss Man (pointy).
+     [office:/pokernight]
+     pointy = 
+  Now assume that the user "pointy" is attempting to browse or
+  checkout the root of the "office" repository.
+  By default (or when the SVNPathAuthz directive is set to "on" in the
+  Apache configuration), Subversion will notice both of the rulesets
+  in the previous configuration file -- the first of which applies to
+  all repositories configured to use this access file to govern
+  authorization, the second of which applies only to the repository
+  named "office".  In such a situation, when the user "pointy"
+  attempts to access the "office" repository, Subversion will grant
+  him or her access to the root of the repository (per the first
+  ruleset), but then deny access to the '/pokernight' top-level
+  subdirectory (per the second ruleset).
+  These access determinations happen because Subversion constructs and
+  issues Apache subrequests to test the access privileges for each and
+  every item in the repository that it considers exposing to the user
+  "pointy".  If any module in the Apache authorization stack denies
+  access to a given path checked in this fashion, that path and its
+  contents are hidden from "pointy".
+  This can be a somewhat expensive operation to perform though, so
+  Subversion administrators who know that the only item in the Apache
+  authorization stack for their Subversion repository locations is
+  Subversion itself may set "SVNPathAuthz short_circuit" in their
+  Apache configuration.  This setting causes Subversion to avoid the
+  Apache subrequest framework altogether and instead query its own
+  access rules directly.  Unfortunately, for servers affected by the
+  bug described herein, Subversion would ignore the second ruleset in
+  the previous example because it has a repository prefix on it -- the
+  "office:" portion of the section's name.  The result would be that
+  the read access granted to "pointy" at the root of the repository
+  would not be overridden for the '/pokernight' subtree, and user
+  "pointy" would indeed be able to view that subtree and its
+  contents.  Poker night at the office would be cancelled.  Or worse,
+  the Boss Man would want to join in, too.
+  Because the same mechanisms are used to govern write permissions,
+  too, this bug could also permit users to write to repository areas
+  that they shouldn't be allowed to write to.
+  Because the same mechanism can be used to grant additional
+  permissions (not merely take them away), this bug could also
+  disallow a user's access to portions of the repository that he or
+  she should be allowed to access.
+  Finally, because Subversion determines access rights for a
+  revision's metadata (log messages, author names, etc.) based on the
+  user's rights to the various files and directories modified in that
+  revision, this bug could grant improper write and/or read access to
+  revision metadata, too.
+  Medium.  An affected server with a particular configuration could
+  leak versioned file contents and metadata, directory metadata, and
+  revision metadata to underprivileged remote users or user classes.
+  Underprivileged remote users could modify repository contents, too,
+  though in the case of file and directory information, no lossage
+  could occur.  (Subversion is, after all, a version control system.)
+  Revision metadata could be silently modified or destroyed, depending
+  on whether the repository was configured to notify users about
+  changes to that information or otherwise keep external records of
+  those changes.
+  We recommend that all users who employ the "SVNPathAuthz short_circuit"
+  configuration directive upgrade to Subversion 1.6.13 immediately.
+  Those who are unable or unwilling to upgrade at this time should
+  consider one or more of the following workarounds:
+  1.  Change the SVNPathAuthz configuration directive's value to "on".
+      This may negatively affect the performance of your Subversion
+      service, but will avoid the problematic logic.  You might need
+      to double-check the rest of your configuration to ensure that
+      taking this step will not inadvertently cause your Subversion
+      authorization checks to pass through extra authorization modules
+      which have thus far been effectively bypassed.
+  2.  Refactor your access files and surrounding Apache configuration
+      so that a given file's rules apply only to a single repository,
+      and then remove any and all repository prefixes from those files.
+      This will allow Subversion's rule matching logic to correctly
+      find all the sections which apply to each repository.  Using the
+      previous example, this would mean creating an access file which
+      governs authorization for the "office" repository only:
+         # All users have read permission on this repository in its
+         # entirety unless otherwise noted.
+         [/]
+         * = r
+         # Hide the '/pokernight' directory of the 'office' repository
+         # from the Boss Man (pointy).
+         [/pokernight]
+         pointy = 
+       ...and also creating similar files for each additional
+       repository previous governed by the original access file.
+  New Subversion packages can be found at:
+  CVE-2010-3313
+Reported by:
+  Kamesh Jayachandran, CollabNet, Inc.
+  C. Michael Pilato, CollabNet, Inc.
+  The following patch applies to Subversion 1.5.x and 1.6.x.
+Index: subversion/mod_dav_svn/authz.c
+--- subversion/mod_dav_svn/authz.c	(revision 1001856)
++++ subversion/mod_dav_svn/authz.c	(working copy)
+@@ -59,7 +59,7 @@
+   allow_read_bypass = dav_svn__get_pathauthz_bypass(r);
+   if (allow_read_bypass != NULL)
+     {
+-      if (allow_read_bypass(r,path, repos->repo_name) == OK)
++      if (allow_read_bypass(r, path, repos->repo_basename) == OK)
+         return TRUE;
+       else
+         return FALSE;

Propchange: subversion/site/publish/security/CVE-2010-3313-advisory.txt
    svn:mime-type = text/plain

Modified: subversion/site/publish/security/index.html
--- subversion/site/publish/security/index.html (original)
+++ subversion/site/publish/security/index.html Fri Oct  1 16:50:59 2010
@@ -74,7 +74,7 @@ Subversion project.</p>
 <td><a href="CAN-2004-0749-advisory.txt">CAN-2004-0749-advisory.txt</a></td>
+<td>1.0.0-1.0.7, 1.1.0-rcX</td>
 <td>Revision metadata leakage in mod_dav_svn.</td>
@@ -92,6 +92,11 @@ Subversion project.</p>
 <td>Heap Overflow in binary delta parser.</td>
+<td><a href="CVE-2010-3313-advisory.txt">CVE-2010-3313-advisory.txt</a></td>
+<td>1.5.0-1.5.7, 1.6.0-1.6.12</td>
+<td>mod_dav_svn exposure of unreadable paths when SVNPathAuthz "short_circuit" is employed.</td>

View raw message