Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 369065 (CVE-2011-1752) - <dev-vcs/subversion-1.6.17: Multiple Vulnerabilities (CVE-2011-{1752,1783,1921})
Summary: <dev-vcs/subversion-1.6.17: Multiple Vulnerabilities (CVE-2011-{1752,1783,1921})
Status: RESOLVED FIXED
Alias: CVE-2011-1752
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL: http://svn.haxx.se/dev/archive-2011-0...
Whiteboard: A3 [glsa]
Keywords:
: 370005 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-28 17:41 UTC by Tim Sammut (RETIRED)
Modified: 2013-09-23 23:15 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Sammut (RETIRED) gentoo-dev 2011-05-28 17:41:26 UTC
#
# NOTE: This issue is currently confidential. Please do not
#       share any information with anyone unless approved by
#       the security team. Thank you.
#

There are three issues being disclosed in Subversion. The draft advisories and patches are below. Upstream has provided us with a prerelease copy of 1.6.17 to prepare. Contact the security team for the URL and credentials.

<--

{{{
===========================================================================
  Subversion HTTP servers up to 1.6.16 (inclusive) are vulnerable to a
  remotely triggerable NULL-pointer dereference.

Summary:
========

  Subversion's mod_dav_svn Apache HTTPD server module will dereference
  a NULL pointer if asked to deliver baselined WebDAV resources.

  This can lead to a DoS.  An exploit has been tested, and tools or users
  have been observed triggering this problem in the wild.

Known vulnerable:
=================

  Subversion HTTPD servers <= 1.6.16

Known fixed:
============

  Subversion 1.6.17
  svnserve (any version) is not vulnerable

Details:
========

  Subversion's mod_dav_svn module implements a subset of the WebDAV
  and DeltaV protocols to support version control operations with
  Subversion clients and, to a limited extent, certain other
  WebDAV-aware client programs.  The protocol dictates the existance
  and use of so-colled "baselined resources" which do not directly
  represent versioned files or directories, but instead represent
  somewhat more abstract concepts.  (See the specifications of those
  protocols for details.)  As a result, these baselined resources --
  which are addressable using specifically formatted URLs -- are not
  suitable for generic delivery in response to the common GET HTTP
  request.

  Because of this vulnerability, mod_dav_svn fails to notice that a
  request submitted against the URL of a baselined resource should
  simply return a graceful error and instead attempts to process the
  request.  This ultimately leads to a dereference of the pointer
  associated with the resource's repository path, which is NULL
  because the resource cannot be said to have such a path.

Severity:
=========

  A remote attacker may be able to crash a Subversion server.  Many Apache
  servers will respawn the listener processes, but a determined attacker
  will be able to crash these processes as they appear, denying service to
  legitimate users.

Recommendations:
================

  We recommend all users to upgrade to Subversion 1.6.17.  Users of
  Subversion 1.5.x or 1.6.x who are unable to upgrade may apply the
  included patch.
  
  New Subversion packages can be found at:
  http://subversion.apache.org/packages.html

References:
===========

  CVE-2011-0715  (Subversion)

Reported by:
============

  Joe Schaefer, Apache Software Foundation
}}}

{{{
===========================================================================
  Subversion HTTP servers 1.5.0 to 1.6.16 (inclusive) are vulnerable
  to a remotely triggerable memory exhaustion DoS vulnerability.

Summary:
========

  Subversion's mod_dav_svn Apache HTTPD server module may in certain
  scenarios enter a logic loop which does not exit and which allocates
  memory in each iteration, ultimately exhausting all the available
  memory on the server.

  This can lead to a DoS.  There are no known instances of this
  problem being observed in the wild, but an exploit has been tested.

Known vulnerable:
=================

  Subversion HTTPD servers >= 1.5.0 and <= 1.6.16

Known fixed:
============

  Subversion 1.6.17
  svnserve (any version) is not vulnerable

Details:
========

  Subversion Apache/mod_dav_svn servers may be configured to provide
  path-based access control for files and directories stored in the
  Subversion repository.

  One such configuration -- identified by the use of the SVNPathAuthz
  httpd.conf directive with a value of "short_circuit" -- instructs
  mod_dav_svn to directly query the authorization logic in
  libsvn_repos to answer access questions ("Does the user who is
  requesting information from this server have permission to read
  SOME-PATH in SOME-REVISION?") rather than employing Apache
  subrequests to do the same.  With such a configuration in place,
  certain data sets and access rule combinations can trigger an
  infinite loop of logic that also allocates memory upon each
  iteration.  Over time, all available system memory will be allocated
  by the logic loop.

Severity:
=========

  A remote attacker may be able to deny access to a Subversion server
  by exhausting the available memory on the server.

Recommendations:
================

  We recommend all users to upgrade to Subversion 1.6.17.  Users of
  Subversion 1.5.x or 1.6.x who are unable to upgrade may apply the
  included patch.
  
  New Subversion packages can be found at:
  http://subversion.apache.org/packages.html

References:
===========

  CVE-2011-1783  (Subversion)

Reported by:
============

  Ivan Zhakov, VisualSVN
}}}

{{{
===========================================================================
  Subversion HTTP servers 1.5.0 to 1.6.16 (inclusive) could leak the
  contents of files configured to be unreadable.

Summary:
========

  Subversion's mod_dav_svn Apache HTTPD server module may leak to
  remote users the file contents of files configured to be unreadable
  by those users.

  There are no known instances of this problem being observed in the
  wild, but an exploit has been tested.

Known vulnerable:
=================

  Subversion HTTPD servers >= 1.5.0 and <= 1.6.16

Known fixed:
============

  Subversion 1.6.17
  svnserve (any version) is not vulnerable

Details:
========

  Subversion Apache/mod_dav_svn servers may be configured to provide
  path-based access control for files and directories stored in the
  Subversion repository.

  In the general case, mod_dav_svn asks access questions ("Does the
  user who is requesting information from this server have permission
  to read SOME-PATH in SOME-REVISION?") of Apache's authorization
  subsystem using Apache's internal subrequest mechanism.  Apache
  partially handles these subrequests, returning either a successful
  or an unsuccessful status code after its authorization subsystem has
  determined whether read access to the requested resource URL has
  been granted or denied, respectively.

  In certain circumstances, mod_dav_svn improperly generates the
  resource URLs that it uses in these subrequests, resulting in
  Apache's authorization subsystem answering the access question for
  the incorrect resource.  Specifically, this leakage is limited to:
  
    * files and directories which are themselves configured to be
      unreadable, but 

    * which are children (immediate or otherwise) of a readable
      directory which itself was copied or moved from an unreadable
      path, and

    * which were present in that directory at the time of its copy or
      move.

    * Finally, the attacker must be using mod_dav_svn's "replay"
      REPORT mechanism to access the extended history of the
      repository.

  NOTE: This vulnerability is not triggerable if mod_dav_svn is
  configured with the "SVNPathAuthz short_circuit" httpd.conf
  directive.  Unfortunately, an independent denial of service
  vulnerability (CVE-2011-1783) prevents the use of this approach
  as a suitable workaround.

Severity:
=========

  File contents of privileged documents could be leaked in full to
  users who shouldn't be permitted to see them.

  NOTE:  We believe this leak is limited to a specific revision of
  those documents -- the revision in which their parent directory was
  copied from an unreadable location -- but have not verified as much.

Recommendations:
================

  We recommend all users to upgrade to Subversion 1.6.17.  Users of
  Subversion 1.5.x or 1.6.x who are unable to upgrade may apply the
  included patch.
  
  New Subversion packages can be found at:
  http://subversion.apache.org/packages.html

References:
===========

  CVE-2011-1921  (Subversion)

Reported by:
============

  Kamesh Jayachandran, CollabNet, Inc.
}}}

===========================================================================
The following patches address all three vulnerabilities.

Patch for Subversion 1.6:
[[[
Index: subversion/mod_dav_svn/repos.c
===================================================================
--- subversion/mod_dav_svn/repos.c	(revision 1128466)
+++ subversion/mod_dav_svn/repos.c	(working copy)
@@ -2843,10 +2843,11 @@
   apr_status_t status;
 
   /* Check resource type */
-  if (resource->type != DAV_RESOURCE_TYPE_REGULAR
-      && resource->type != DAV_RESOURCE_TYPE_VERSION
-      && resource->type != DAV_RESOURCE_TYPE_WORKING
-      && resource->info->restype != DAV_SVN_RESTYPE_PARENTPATH_COLLECTION)
+  if (resource->baselined
+      || (resource->type != DAV_RESOURCE_TYPE_REGULAR
+          && resource->type != DAV_RESOURCE_TYPE_VERSION
+          && resource->type != DAV_RESOURCE_TYPE_WORKING
+          && resource->info->restype != DAV_SVN_RESTYPE_PARENTPATH_COLLECTION))
     {
       return dav_new_error(resource->pool, HTTP_CONFLICT, 0,
                            "Cannot GET this type of resource.");
Index: subversion/mod_dav_svn/authz.c
===================================================================
--- subversion/mod_dav_svn/authz.c	(revision 1126811)
+++ subversion/mod_dav_svn/authz.c	(working copy)
@@ -46,6 +46,11 @@ dav_svn__allow_read(request_rec *r,
       return TRUE;
     }
 
+  /* Sometimes we get paths that do not start with '/' and 
+     hence below uri concatenation would lead to wrong uris .*/
+  if (path && path[0] != '/')
+    path = apr_pstrcat(pool, "/", path, NULL);
+
   /* If bypass is specified and authz has exported the provider.
      Otherwise, we fall through to the full version.  This should be
      safer than allowing or disallowing all accesses if there is a
Index: subversion/libsvn_repos/authz.c
===================================================================
--- subversion/libsvn_repos/authz.c	(revision 1126811)
+++ subversion/libsvn_repos/authz.c	(working copy)
@@ -746,6 +746,9 @@ svn_repos_authz_check_access(svn_authz_t *authz, c
       return SVN_NO_ERROR;
     }
 
+  /* Sanity check. */
+  SVN_ERR_ASSERT(path[0] == '/');
+
   /* Determine the granted access for the requested path. */
   while (!authz_get_path_access(authz->cfg, repos_name,
                                 current_path, user,
]]]

Patch for Subversion 1.5:
[[[
Index: subversion/libsvn_repos/authz.c
===================================================================
--- subversion/libsvn_repos/authz.c	(revision 1124570)
+++ subversion/libsvn_repos/authz.c	(working copy)
@@ -748,6 +748,13 @@
       return SVN_NO_ERROR;
     }
 
+  /* Sanity check. */
+  if (path[0] != '/')
+    {
+      return svn_error_createf(SVN_ERR_INCORRECT_PARAMS, NULL,
+                               "%s should be an absolute path", path);
+    }
+
   /* Determine the granted access for the requested path. */
   while (!authz_get_path_access(authz->cfg, repos_name,
                                 current_path, user,
Index: subversion/mod_dav_svn/authz.c
===================================================================
--- subversion/mod_dav_svn/authz.c	(revision 1124570)
+++ subversion/mod_dav_svn/authz.c	(working copy)
@@ -51,6 +51,11 @@
       return TRUE;
     }
 
+  /* Sometimes we get paths that do not start with '/' and 
+     hence below uri concatenation would lead to wrong uris .*/
+  if (path && path[0] != '/')
+    path = apr_pstrcat(pool, "/", path, NULL);
+
   /* If bypass is specified and authz has exported the provider.
      Otherwise, we fall through to the full version.  This should be
      safer than allowing or disallowing all accesses if there is a
]]]
Comment 1 Alex Legler (RETIRED) archtester gentoo-dev Security 2011-06-04 11:17:44 UTC
Public as per $URL.

Arfrever: ping
Comment 2 Alex Legler (RETIRED) archtester gentoo-dev Security 2011-06-04 11:17:55 UTC
*** Bug 370005 has been marked as a duplicate of this bug. ***
Comment 3 GLSAMaker/CVETool Bot gentoo-dev 2011-06-13 18:11:41 UTC
CVE-2011-1921 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1921):
  The mod_dav_svn module for the Apache HTTP Server, as distributed in Apache
  Subversion 1.5.x and 1.6.x before 1.6.17, when the SVNPathAuthz
  short_circuit option is disabled, does not properly enforce permissions for
  files that had been publicly readable in the past, which allows remote
  attackers to obtain sensitive information via a replay REPORT operation.

CVE-2011-1783 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1783):
  The mod_dav_svn module for the Apache HTTP Server, as distributed in Apache
  Subversion 1.5.x and 1.6.x before 1.6.17, when the SVNPathAuthz
  short_circuit option is enabled, allows remote attackers to cause a denial
  of service (infinite loop and memory consumption) in opportunistic
  circumstances by requesting data.

CVE-2011-1752 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1752):
  The mod_dav_svn module for the Apache HTTP Server, as distributed in Apache
  Subversion before 1.6.17, allows remote attackers to cause a denial of
  service (NULL pointer dereference and daemon crash) via a request for a
  baselined WebDAV resource, as exploited in the wild in May 2011.
Comment 4 Nathan March 2011-08-15 20:54:43 UTC
This security bug is almost 3 months old now with no sign of any action, is something holding this back? Looks to be a trivial upgrade from 1.6.16 to 1.6.17, probably just requires an ebuild version bump...
Comment 5 Tony Vroon (RETIRED) gentoo-dev 2011-08-17 11:50:38 UTC
(In reply to comment #4)
> This security bug is almost 3 months old now with no sign of any action, is
> something holding this back? Looks to be a trivial upgrade from 1.6.16 to
> 1.6.17, probably just requires an ebuild version bump...

The maintainer in charge of the ebuild is no longer a developer. My apologies, this is an unacceptable response time. I have taken maintainership of this ebuild, and plan to give it some much needed love in the near future.
For now, the version bump is in place.

+*subversion-1.6.17 (17 Aug 2011)
+
+  17 Aug 2011; Tony Vroon <chainsaw@gentoo.org> +subversion-1.6.17.ebuild,
+  metadata.xml:
+  Version bump for security bug #369065 by Tim Sammut. Took maintainership,
+  added use of base eclass and PATCHES bash array. EAPI 4 usage made impossible
+  by python eclass.
Comment 6 Tony Vroon (RETIRED) gentoo-dev 2011-08-17 11:58:36 UTC
Arches, please test & mark stable. A portage.internal & upstream.workaround warning from repoman are expected, these will be resolved in later ebuilds when the time pressure is off.
Comment 7 Agostino Sarubbo gentoo-dev 2011-08-17 14:53:10 UTC
amd64 ok
Comment 8 Markos Chandras (RETIRED) gentoo-dev 2011-08-17 15:01:47 UTC
amd64 done. Thanks Agostino
Comment 9 Kacper Kowalik (Xarthisius) (RETIRED) gentoo-dev 2011-08-18 09:33:52 UTC
ppc/ppc64 stable
Comment 10 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2011-08-18 16:48:43 UTC
x86 stable
Comment 11 Nathan March 2011-08-18 16:55:17 UTC
Thanks Tony for giving this a nudge =)
Comment 12 Markus Meier gentoo-dev 2011-08-24 18:20:27 UTC
arm stable
Comment 13 Jeroen Roovers (RETIRED) gentoo-dev 2011-08-25 17:06:16 UTC
Stable for HPPA.
Comment 14 Raúl Porcel (RETIRED) gentoo-dev 2011-08-27 11:21:05 UTC
alpha/ia64/s390/sh/sparc stable
Comment 15 Tim Sammut (RETIRED) gentoo-dev 2011-08-27 16:37:45 UTC
Thanks, everyone. Added to existing GLSA request.
Comment 16 GLSAMaker/CVETool Bot gentoo-dev 2013-09-23 23:15:29 UTC
This issue was resolved and addressed in
 GLSA 201309-11 at http://security.gentoo.org/glsa/glsa-201309-11.xml
by GLSA coordinator Sean Amoss (ackle).