# # 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 ]]]
Public as per $URL. Arfrever: ping
*** Bug 370005 has been marked as a duplicate of this bug. ***
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.
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...
(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.
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.
amd64 ok
amd64 done. Thanks Agostino
ppc/ppc64 stable
x86 stable
Thanks Tony for giving this a nudge =)
arm stable
Stable for HPPA.
alpha/ia64/s390/sh/sparc stable
Thanks, everyone. Added to existing GLSA request.
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).
