Subversion 1.8.0 Assertion failed remote DoS

2013.08.01
Credit: Daniel Shahaf
Risk: Medium
Local: No
Remote: Yes
CWE: N/A


CVSS Base Score: 4/10
Impact Subscore: 2.9/10
Exploitability Subscore: 8/10
Exploit range: Remote
Attack complexity: Low
Authentication: Single time
Confidentiality impact: None
Integrity impact: None
Availability impact: Partial

Subversion HTTP servers up to 1.8.0 (inclusive) are vulnerable to a remotely triggerable "Assertion failed" DoS vulnerability or read overflow. Summary: ======== Subversion's mod_dav_svn Apache HTTPD server module will trigger an assertion on some requests made against a revision root. This can lead to a DoS. If assertions are disabled it will trigger a read overflow which may cause a SEGFAULT (or equivalent) or undefined behavior. Commit access is required to exploit this. Known vulnerable: ================= Subversion HTTPD servers 1.7.0 through 1.7.10 (inclusive). Subversion HTTPD servers 1.8.0 (including 1.8.0 release candidates). Known fixed: ============ Subversion 1.8.1 Subversion 1.7.11 svnserve (any version) is not vulnerable. Subversion 1.6.x is not vulnerable. Details: ======== The vulnerability can be triggered in two ways. The first way requires that the Subversion server runs Apache HTTPD 2.2.25 or later or Apache HTTPD 2.4.5 or later. When running under those versions of Apache HTTPD, the vulnerability can be triggered by making a COPY request against a revision root. The following Subversion operation generates such a request: % svn cp -mm ^/ ^/foo With any version of Apache HTTPD, the vulnerability may be triggered by making a DELETE HTTP request against a revision root, a MOVE HTTP request whose source or destination is a revision root, or a COPY HTTP request whose destination is a revision root. These requests are not part of any valid Subversion operation. Making a copy of the repository root is a valid Subversion operation. However, a code change in Apache HTTPD 2.2.25/2.4.5 led to a codepath being exercised for a revision root that was never before executed for a revision root. That code performs a hand-rolled path arithmetic instead of using the internal path manipulation library, and thus passes an invalid path down to a library function which runs an assert() validation on that path. When assertions are enabled, the validation fails and kills the httpd process. When assertions are disabled, code would read beyond allocated memory, which may lead to a segfault or undefined behavior. Severity: ========= CVSSv2 Base Score: 4 CVSSv2 Base Vector: AV:N/AC:L/Au:S/C:N/I:N/A:P How bad the impact of that is varies based upon several environmental configuration details. Specifically whether assertions were enabled at build time and what MPM mode Apache httpd is using. When assertions are enabled (defaults to on for *nix systems and off for Windows) then the assertion will prevent any undefined behavior, at the cost of a causing the http server process to abort. Apache httpd servers using a prefork MPM will simply start a new process to replace the process that died. Servers using threaded MPMs may be processing other requests in the same process as the process that the attack causes to die. In either case there is an increased processing impact of restarting a process and the cost of per process caches being lost. When assertions are disabled a read overflow will occur. This may cause a segfault. However, it may also simply read into other memory that was allocated and as a result the precise behavior of Subversion is partially undefined. Subversion may accept or reject the request when it should not do so based on locks, "If:" http headers or ETags. We have not found any cases where the contents of the memory that has been read into will be leaked to the client or into the repository. Recommendations: ================ We recommend all users to upgrade to Subversion 1.8.1 or 1.7.11. Users who are unable to upgrade may apply the included patches. New Subversion packages can be found at: http://subversion.apache.org/packages.html We remind users that we recommend upgrading Apache HTTPD to 2.2.25 (for repositories served by HTTPD) due to an independent security issue fixed in that HTTPD release: CVE-2013-1896. See <http://s.apache.org/H1a> for details about CVE-2013-1896, including a recommendation for those who serve Subversion repositories with Apache HTTPD 2.4.x. References: =========== CVE-2013-4131 (Subversion) Reported by: ============ Daniel Shahaf, Apache Infrastructure Patches: ======== Patch for Subversion 1.7.x and 1.8.0: [[[ Index: subversion/mod_dav_svn/repos.c =================================================================== --- subversion/mod_dav_svn/repos.c (revision 1503527) +++ subversion/mod_dav_svn/repos.c (revision 1503528) @@ -2408,21 +2408,12 @@ svn_boolean_t is_urlpath, apr_pool_t *pool) { - apr_size_t len; - char *tmp = apr_pstrdup(pool, path); - - len = strlen(tmp); - - if (len > 0) + if (*path != '\0') /* not an empty string */ { - /* Remove any trailing slash; else svn_path_dirname() asserts. */ - if (tmp[len-1] == '/') - tmp[len-1] = '\0'; - if (is_urlpath) - return svn_urlpath__dirname(tmp, pool); + return svn_urlpath__dirname(path, pool); else - return svn_fspath__dirname(tmp, pool); + return svn_fspath__dirname(path, pool); } return path; @@ -2458,7 +2449,9 @@ parent->versioned = 1; parent->hooks = resource->hooks; parent->pool = resource->pool; - parent->uri = get_parent_path(resource->uri, TRUE, resource->pool); + parent->uri = get_parent_path(svn_urlpath__canonicalize(resource->uri, + resource->pool), + TRUE, resource->pool); parent->info = parentinfo; parentinfo->uri_path = ]]]

References:

https://bugzilla.redhat.com/show_bug.cgi?id=986194
http://xforce.iss.net/xforce/xfdb/85983
http://www.securityfocus.com/bid/61454
http://subversion.apache.org/security/CVE-2013-4131-advisory.txt


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top