==================================================================== CERT-Renater Note d'Information No. 2016/VULN184 _____________________________________________________________________ DATE : 03/05/2016 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Apache Subversion version prior to 1.9.4, 1.8.16. ====================================================================== https://subversion.apache.org/security/CVE-2016-2167-advisory.txt https://subversion.apache.org/security/CVE-2016-2168-advisory.txt ____________________________________________________________________ svnserve/sasl may authenticate users using the wrong realm Summary: ======== svnserve, the svn:// protocol server, can optionally use the Cyrus SASL library for authentication, integrity protection, and encryption. Due to a programming oversight, authentication against Cyrus SASL would permit the remote user to specify a realm string which is a prefix of the expected realm string. Known vulnerable: ================= Subversion 1.9.0 to 1.9.3 Subversion 1.5.0 to 1.8.15 Only repositories served by svnserve using SASL are affected. For a repository to be affected, both of the following must be true: 1. The output of `svnserve --version` includes the line "Cyrus SASL authentication is available". 2. The svnserve.conf file includes "use-sasl = true" in the "[sasl]" section. Known fixed: ============ Subversion 1.9.4 Subversion 1.8.16 mod_dav_svn (any version) is not affected. svnserve compiled without SASL support is not affected, regardless of the contents of svnserve.conf files. If the svnserve.conf file specifies 'use-sasl = false', or does not specify 'use-sasl' at all, then the repository or svnserve instance using that svnserve.conf file is not affected. Details: ======== The Cyrus SASL authentication library provides a callback for applications to "canonicalize" the username and realm provided by the remote end. svnserve uses that callback to enforce that either the remote end specified no realm, or it specified the repository's realm (as declared in the svnserve.conf file). Due to a programming oversight, if the remote end specified a realm string which is a prefix of the expected realm string, the remote-specified realm string would be used in the canonicalized value. Consequently, a user who has valid credentials to a realm, whose name is a prefix of the repository's realm, would be able to successfully authenticate to the repository. Such a user would still be subject to path-based authorization, if enabled via the 'authz-db' or 'auth-access' svnserve.conf directives. In theory, the erroneous realm comparison would also allow a remote user to specify a realm string followed by an ASCII NUL byte and possibly by more bytes thereafter. In practice, however, control flow on such inputs does not reach the vulnerable code. Examples: 1. The user "jrandom" in the realm "foo" can successfully authenticate to a repository whose realm is "foobar". Severity: ========= CVSSv2 Base Score: 3.6 CVSSv2 Base Vector: AV:N/AC:H/Au:S/C:P/I:P/A:N Since this vulnerability presupposes rare circumstances --- namely, having a valid realm name which is a string prefix of the repository's realm name --- few deployments will be affected. For affected deployments, however, this is a medium-risk information disclosure and modification vulnerability. The extent of the information that may be accessed and modified by attackers depends on the path-based authorization configuration in use (via the 'authz-db' and 'auth-access' svnserve.conf directives). Recommendations: ================ Affected servers should be upgraded to Subversion 1.8.16 or 1.9.4. Workarounds include: - Use path-based authorization to deny access to usernames from other realms, so they would be able to authenticate but then would have authorization to nothing. - Change realm names such that no valid realm name is a prefix of the repository's realm name. References: =========== CVE-2016-2167 (Subversion) Reported by: ============ Daniel Shahaf, Apache Infrastructure James McCoy, Debian Patches: ======== Patch for Subversion 1.9.3: [[[ Index: subversion/svnserve/cyrus_auth.c =================================================================== - --- subversion/svnserve/cyrus_auth.c (revision 1735379) +++ subversion/svnserve/cyrus_auth.c (working copy) @@ -74,6 +74,8 @@ static int canonicalize_username(sasl_conn_t *conn { /* The only valid realm is user_realm (i.e. the repository's realm). If the user gave us another realm, complain. */ + if (realm_len != inlen-(pos-in+1)) + return SASL_BADPROT; if (strncmp(pos+1, user_realm, inlen-(pos-in+1)) != 0) return SASL_BADPROT; } ]]] Patch for Subversion 1.8.15: [[[ Index: subversion/svnserve/cyrus_auth.c =================================================================== - --- subversion/svnserve/cyrus_auth.c (revision 1735379) +++ subversion/svnserve/cyrus_auth.c (working copy) @@ -74,6 +74,8 @@ static int canonicalize_username(sasl_conn_t *conn { /* The only valid realm is user_realm (i.e. the repository's realm). If the user gave us another realm, complain. */ + if (realm_len != inlen-(pos-in+1)) + return SASL_BADPROT; if (strncmp(pos+1, user_realm, inlen-(pos-in+1)) != 0) return SASL_BADPROT; } ]]] - --- ____________________________________________________________________ Remotely triggerable DoS vulnerability in mod_authz_svn during COPY/MOVE authorization check. Summary: ======== Subversion's httpd servers are vulnerable to a remotely triggerable crash in the mod_authz_svn module. The crash can occur during an authorization check for a COPY or MOVE request with a specially crafted header value. This allows remote attackers to cause a denial of service. Known vulnerable: ================= Subversion httpd servers 1.0.0 to 1.8.15 (inclusive) Subversion httpd servers 1.9.0 through 1.9.3 (inclusive) Subversion svnserve servers (any version) are not vulnerable Known fixed: ============ Subversion 1.8.16 Subversion 1.9.4 Details: ======== Subversion includes a separate server module, mod_authz_svn, which does path-based authorization on Subversion repositories. Authorizing a COPY or MOVE request requires additional checks for the destination of the request. This additional logic contains a flaw that will cause a null pointer dereference and a segmentation fault with certain invalid request headers. Exploiting this vulnerability requires the attacker to be authenticated on the targeted server. Since the flaw is in the authorization module, the attack does not require access to a particular repository. Severity: ========= CVSSv2 Base Score: 5.0 CVSSv2 Base Vector: AV:N/AC:L/Au:N/C:N/I:N/A:P We consider this to be a medium risk vulnerability. In order to take advantage of this attack the attacker would require to authenticate against the targeted server. The attack does not require read access to a particular repository. Servers which allow for anonymous reads will be vulnerable without authentication. 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. Servers using threaded MPMs will close the connection on other clients being served by the same process that services the request from the attacker. In either case there is an increased processing impact of restarting a process and the cost of per process caches being lost. Recommendations: ================ We recommend all users to upgrade to Subversion 1.9.4. Users of Subversion 1.8.x and 1.9.x who are unable to upgrade may apply the included patch. New Subversion packages can be found at: http://subversion.apache.org/packages.html No workaround is available. References: =========== CVE-2016-2168 (Subversion) Reported by: ============ Ivan Zhakov, VisualSVN Patches: ======== Patch for Subversion 1.9.3: [[[ Index: subversion/mod_authz_svn/mod_authz_svn.c =================================================================== - --- subversion/mod_authz_svn/mod_authz_svn.c (revision 1736295) +++ subversion/mod_authz_svn/mod_authz_svn.c (working copy) @@ -639,6 +639,8 @@ req_check_access(request_rec *r, if (r->method_number == M_MOVE || r->method_number == M_COPY) { + apr_status_t status; + dest_uri = apr_table_get(r->headers_in, "Destination"); /* Decline MOVE or COPY when there is no Destination uri, this will @@ -647,7 +649,19 @@ req_check_access(request_rec *r, if (!dest_uri) return DECLINED; - - apr_uri_parse(r->pool, dest_uri, &parsed_dest_uri); + status = apr_uri_parse(r->pool, dest_uri, &parsed_dest_uri); + if (status) + { + ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, + "Invalid URI in Destination header"); + return HTTP_BAD_REQUEST; + } + if (!parsed_dest_uri.path) + { + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, + "Invalid URI in Destination header"); + return HTTP_BAD_REQUEST; + } ap_unescape_url(parsed_dest_uri.path); dest_uri = parsed_dest_uri.path; ]]] Patch for Subversion 1.8.15: [[[ Index: subversion/mod_authz_svn/mod_authz_svn.c =================================================================== - --- subversion/mod_authz_svn/mod_authz_svn.c (revision 1736295) +++ subversion/mod_authz_svn/mod_authz_svn.c (working copy) @@ -628,6 +628,8 @@ req_check_access(request_rec *r, if (r->method_number == M_MOVE || r->method_number == M_COPY) { + apr_status_t status; + dest_uri = apr_table_get(r->headers_in, "Destination"); /* Decline MOVE or COPY when there is no Destination uri, this will @@ -636,7 +638,19 @@ req_check_access(request_rec *r, if (!dest_uri) return DECLINED; - - apr_uri_parse(r->pool, dest_uri, &parsed_dest_uri); + status = apr_uri_parse(r->pool, dest_uri, &parsed_dest_uri); + if (status) + { + ap_log_rerror(APLOG_MARK, APLOG_ERR, status, r, + "Invalid URI in Destination header"); + return HTTP_BAD_REQUEST; + } + if (!parsed_dest_uri.path) + { + ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, + "Invalid URI in Destination header"); + return HTTP_BAD_REQUEST; + } ap_unescape_url(parsed_dest_uri.path); dest_uri = parsed_dest_uri.path; ]]] ========================================================== Serveur de référence du CERT-Renater https://services.renater.fr/ssi/ ========================================================== + CERT-RENATER | tel : 01-53-94-20-44 + + 23 - 25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email: cert@support.renater.fr + ==========================================================