Created attachment 382374 [details, diff] serf CVE-2014-3504 patch This email is a confidential pre-notification for multiple security alerts for Subversion clients: * CVE-2014-3522 * CVE-2014-3528 Additionally, this confidential pre-notification includes a security alert for the Serf library: * CVE-2014-3504 Please *do not forward* any part of this mail to anyone. The public announcement is not until 11 August 2014 16:00 UTC, and we'd like to keep the information embargoed until then. You are receiving this mail because (we think) you distribute software that uses the Subversion libraries or that you host a Subversion installation used by a large number of users. We believe that you might want to have your software patched by the time these security holes are made public on 11 August (CVE-2014-3528 is already public, but very low risk). If you no longer maintain Subversion-related packages or hosting, please reply to this mail indicating who the appropriate contact would be for your organization. Below are the advisories, followed by patches to fix the problems. The Subversion patches apply to Subversion 1.7.17 and Subversion 1.8.9. Subversion 1.7.18 and 1.8.10 will will be published on 11 August, including the patches below, as well as other stability and bug fixes. You can get an advance copy of the source distribution here: https://dist.apache.org/repos/dist/dev/subversion/ The Serf patch applies against 1.3.6. Serf 1.3.7 will be published on 11 August, and only includes this change. Here are the full advisories: {{{ Subversion's Serf RA layer does not correctly validate certificates with wildcards in them for HTTPs. Summary: ======== Subversion's Serf RA layer improperly evaulates wildcards for HTTPs. This means it will accept certificates that it should not accept as matching the hostname the client is using to make the request. This can lead to a man-in-the-middle attack. There are no known instances of this problem being exploited in the wild and in practice it should be difficult to actually exploit this vulnerability. Known vulnerable: ================= Subversion clients using Serf 1.4.0 through 1.7.17 (inclusive) Subversion clients using Serf 1.8.0 through 1.8.9 (inclusive) Known fixed: ============ Subversion 1.7.18 Subversion 1.8.10 Subversion clients not using HTTPs or using Neon. Details: ======== Using the Serf RA layer of Subversion for HTTPs uses the apr_fnmatch API to handle matching wildcards in certificate Common Names and Subject Alternate Names. However, apr_fnmatch is not designed for this purpose. Instead it is designed to behave like common shell globbing. In particular this means that '*' is not limited to a single label within a hostname (i.e. it will match '.'). But even further apr_fnmatch supports '?' and character classes (neither of which are part of the RFCs defining how certificate validation works). For HTTPs URLs Subversion has historically been able to use one of two HTTP libraries, Serf or Neon. Serf support was first added as a build time option in Subversion 1.4.0, which meant only Serf or Neon was available in a given build of Subversion. Starting with 1.5.0 Subversion supported building support for both Serf and Neon and choosing which one to use based on a run-time configuration option. Subversion 1.8.0 removed support for Neon. Clients using Neon are not vulnerable to this issue, since the Neon library itself implements the name validation and does so correctly. Users can see if their client supports serf by running `svn --version` and looking to see if the ra_serf repository access module is available. Severity: ========= CVSSv2 Base Score: 4.0 CVSSv2 Base Vector: AV:N/AC:H/Au:N/C:P/I:P/A:N We consider this to be a medium risk vulnerability. Taking advantage of this vulnerability to execute a man in the middle attack requires access to the network or DNS of the client in order to redirect it to the attackers server. Additionally, the attacker needs a certificate signed by an issuer that the client trusts. The most concerning aspect of this vulnerability is the '*' wildcard matching across hostname labels. This for instance could allow a certificate with the Common Name set to only "*" to be matched against any hostname. Another possiblity would be for an attacker to try and get a certificate signed for a domain they control that is a suffix for the domain they wish to attack. For example if attacking "example.com" the attacker could try registering "ample.com" and then request a certificate for "*ample.com" (note the lack of a '.' between the '*' and 'a'). However, issuers should not be signing such certificates. This issue when combined with the Serf vulnerability CVE-2014-3504, does however, make things slightly worse. CVE-2014-3504 means that serf does not properly handle certificates with embedded NUL bytes in their Common Names or Subject Alternate Names. So an attacker could request a certificate with the Common Name of "*\0.example.com" where "\0" is a NUL byte and ".example.com" is a domain the attacker owns. Such a certificate would be matched for any hostname. Again issuers should not be signing such certificates. There is of course no requirement that the attacker use certificates signed by a Certifying Authority. However, if an end user is going to accept the certificate (without fingerprint verification) despite an error telling them it is not certified by a trusted authority then this vulnerability is not needed to man-in-the-middle that user. Since the attacker can simply generate a certificate with the expected values. As such, useful explotation of this vulnerability comes from getting a trusted Certifying Authority to sign a certificate the client will accept. A successful man-in-the-middle attack would give the attacker access to the plaintext of the encrypted communications between the client and the server. This would expose any information from the repository the client has requested. It may expose authentication credentials which can be used by the attacker to impersonante the user of the attacked client and thus gain access to more information or even be able to modify the repository. In all cases the attacker would still be subject to any authorizaton rules configured on the repository. Recommendations: ================ We recommend all users to upgrade to Subversion 1.8.10. Users of Subversion 1.7.x or 1.8.x who are unable to upgrade may apply the included patch. We also recommend that all users upgrade to Serf 1.3.7 or newer to resolve CVE-2014-3504. New Subversion packages can be found at: http://subversion.apache.org/packages.html There are no workarounds available. However, some of the risk can be mitigated by users taking some care. Users should not accept certificates that are not signed by a trusted certifying authority, without verifying their authenticity via the fingerprint. Users may also configure their clients not to trust certifying authorities (or decrease the number of certifying authorities they trust). Unfortunately, these mitigating steps require a great deal of care on the part of users, so upgrading the client immediately is the best course of action. References: =========== CVE-2014-3522 (Subversion) CVE-2014-3504 (Serf - different but related vulnerability) Reported by: ============ Ben Reser, WANdisco Patches: ======== Patch against 1.7.17: (attached to bug) }}} {{{ Credentials cached with Subversion may be sent to the wrong server. Summary: ======== Subversion's credentials cache uses a MD5 hash in order to index and then lookup cached credentials. MD5 is subject to hash collisions and as such it may be possible to engineer a server to get Subversion to send it credentials that have been cached for a different server. This can lead to the leaking of these credentials to a 3rd party. Known vulnerable: ================= Subversion clients 1.0.0 through 1.7.17 (inclusive) Subversion clients 1.8.0 through 1.8.9 (inclusive) Known fixed: ============ Subversion 1.7.18 Subversion 1.8.10 Details: ======== Subversion stores cached credentials by an MD5 hash based on the URL and the authentication realm of the server the credentials are cached for. MD5 has been shown to be subject to chosen plaintext hash collisions. This means it may be possible to generate an authentication realm which results in the same MD5 hash for a different URL. Subversion supports storage of the credentials in a variety of ways (e.g. Windows Crypto API, KWallet, Gnome-Keyring, and the OS X Keychain) as well as its own built in storage. This vulnerability applies to all of them since the same hash key is used to store the credentials in all of them. Severity: ========= CVSSv2 Base Score: 4.0 CVSSv2 Base Vector: AV:N/AC:H/Au:N/C:P/I:P/A:N We consider this to be a very low risk vulnerability. Exploiting this vulnerability in practice will be very difficult. Calculating such a collision with the current public known techniques for producing an MD5 collision (e.g chosen prefix attacks) requires control of the authentication realm on the real server the credentials are for. Typically if you have access to modify the authentication realm you already have more access than the credentials can gain you or can log credentials in other less visible ways. However, it is possible that other techniques are unknown to the public or will become known in the future that allow MD5 pre-image attacks such that the attacker does not need to change the authentication realm on the real server. Even once an attacker has calculated an authentication realm for the server they wish to steal credentials for they have to get the Subversion client to connect to their server with this configuration in place. This would likely require some social engineering to get a user to do this. However, there would be nothing to indicate to the user that such a situation was occurring. Recommendations: ================ We recommend all users to upgrade to Subversion 1.8.10. Users of Subversion 1.7.x or 1.8.x who are unable to upgrade may apply the included patch. New Subversion packages can be found at: http://subversion.apache.org/packages.html Users can avoid this problem by disabling authentication credential storage via the 'store-auth-creds' setting in the '[global]' section of the Subversion servers configuration file. See the SVN Book for details on where to find these configuration files: http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html References: =========== CVE-2014-3528 (Subversion) Reported by: ============ Bert Huijben, CollabNet Patches: ======== Patch against 1.7.17: (attached to bug) }}} {{{ Serf may not provide the full value for fields contained in X.509 certificates. Allowing for clients to potentially improperly accept certificates. Summary: ======== Serf provides APIs to retrieve information about a certificate. These APIs return the information as NUL terminated strings (commonly called C strings). X.509 uses counted length strings which may include a NUL byte. This means that a library user will interpret any information as ending upon seeing this NUL byte and will only see a partial value for that field. Attackers could exploit this vulnerability to create a certificate that a client will accept for a different hostname than the full certificate is actually for by embedding a NUL byte in the certificate. This can lead to a man-in-the-middle attack. There are no known instances of this problem being exploited in the wild and in practice it should be difficult to actually exploit this vulnerability. Known vulnerable: ================= Serf 0.2.0 through 1.3.6 (inclusive) Known fixed: ============ Serf 1.3.7 Details: ======== Since 0.2.0 Serf has provided a callback for the library user to validate server certificates. A serf_ssl_certificate_t structure is provided to that callback along with accessor functions that return information from the certificate described in that structure. These functions return a hash that then ultimately returns the string values as NUL byte terminated strings (C strings) to the library user. As a result of this clients using serf_ssl_cert_issuer(), serf_ssl_cert_subject() or serf_ssl_cert_certificate() to retrieve string values may be subject to NUL byte poisoning. Which occurs when a NUL byte is included in a field of a certificate with the intention of shortening the value that the software actually sees. For example a certificate with the Common Name "www.example.com\0.example.net" (where \0 is a NUL byte) would appear to the library user as "www.example.com" even though the certificate is actually issued for a subdomain of "example.net". A client using these strings to validate the hostname would accept that certificate for "www.example.com". Severity: ========= CVSSv2 Base Score: 4.0 CVSSv2 Base Vector: AV:N/AC:H/Au:N/C:P/I:P/A:N We consider this to be a medium risk vulnerability. Taking advantage of this vulnerability to execute a man in the middle attack requires access to the network or DNS of the client in order to redirect it to the attackers server. Additionally, the attacker needs a certificate signed by an issuer that the client trusts. This issue is not unknown to the security community and received widespread publicity in 2009 when Dan Kaminsky and Moxie Marlinspike presented talks at Black Hat about this issue. As a result Certifying Authorities should not be signing certificates with NUL bytes. This should make exploiting this vulnerability much more difficult in practice. Certificates that are not signed by a Certifying Authority are not likely to need to use such a vulnerability. Since they could simply produce a certificate that had the expected value and if users are not verifying the authenticity of such certificates by checking the fingerprint they may wrongly accept the certificate. As a result we believe that it would be actually very hard to actually execute such an attack in the real world. You'd need to find a Certifying Authority that the client trusted and that failed to reject signing such certificates. A successful man-in-the-middle attack would give the attacker access to the plaintext of the encrypted communications between the client and the server. This may expose authentication credentials which can be used by the attacker to impersonante the user of the attacked client and thus gain access to more information or even be able to make changes on the server. In all cases the attacker would still be subject to any authorizaton requirements configured on the server. Recommendations: ================ We recommend all users to upgrade to Serf 1.3.7. Users of Serf 1.3.x who are unable to upgrade may apply the included patch. The Serf 1.3.7 release can be found at: https://code.google.com/p/serf/ Library users can avoid using the provided API functions and handle parsing the X.509 certificate on their own. This is not an entirely trivial undertaking and should not be undertaken lightly. References: =========== CVE-2014-3504 (Serf) CWE-297 (Improper Validation of Certificate with Host Mismatch) Reported by: ============ Ben Reser, WANdisco Patches: ======== Patch against 1.3.6: (attached to bug) }}}
Created attachment 382376 [details, diff] Subversion CVE-2014-2522 patch
Created attachment 382378 [details, diff] Subversion CVE-2014-3528 patch
I am not sure why I am copied on this bug; I do not maintain the subversion package. Also, polynomial-c is listed as a maintainer but is not copied on this bug.
(In reply to Mike Gilbert from comment #3) > I am not sure why I am copied on this bug; I do not maintain the subversion > package. > > Also, polynomial-c is listed as a maintainer but is not copied on this bug. This is obviously a mistake, I am un-CCing you. Please do not disclose this info, as said in first message. CCing Polynomial-C as he is marked as Subversion 1.8.* maintainer
+*subversion-1.8.10 (12 Aug 2014) + + 12 Aug 2014; Lars Wendler <polynomial-c@gentoo.org> -subversion-1.8.8.ebuild, + +subversion-1.8.10.ebuild: + Security bump (bug #519202). Removed old. Added pkg_pretend which fails if + USE=test is set and an old version of this package is installed (bug + #516054). Don't run tests with USE=dso. + Arches please test and mark stable =dev-vcs/subversion-1.8.10 with target KEYWORDS: alpha amd64 arm arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 ~ppc-aix ~amd64-fbsd ~x86-fbsd ~x86-freebsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris
What happened to 1.7.18? Is 1.7.* on its way out after stabilisation?
Stable for HPPA.
Wait, what happened to net-libs/serf?
(In reply to Jeroen Roovers from comment #6) > What happened to 1.7.18? Is 1.7.* on its way out after stabilisation? i just missed this bug, 1.7.18 is now added to the tree. Arches, please test and stabilize =dev-vcs/subversion-1.7.18 target KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~mips ppc ppc64 ~s390 ~sh sparc x86 ~ppc-aix ~amd64-fbsd ~x86-fbsd ~x86-freebsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
amd64 stable
x86 stable
alpha/arm/arm64/ia64/sparc stable
Readding arches back, cause they also need to stabilize net-libs/serf in this bug too. Arches, please test and mark stable =net-libs/serf-1.3.7 Target keywords: alpha arm arm64 hppa ia64 ppc ppc64 sparc x86
alpha/arm/arm64/ia64/sparc/x86 stable
ppc stable
CVE-2014-3528 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3528): Apache Subversion 1.0.0 through 1.7.x before 1.7.17 and 1.8.x before 1.8.10 uses an MD5 hash of the URL and authentication realm to store cached credentials, which makes it easier for remote servers to obtain the credentials via a crafted authentication realm. CVE-2014-3522 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3522): The Serf RA layer in Apache Subversion 1.4.0 through 1.7.x before 1.7.18 and 1.8.x before 1.8.10 does not properly handle wildcards in the Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof servers via a crafted certificate. CVE-2014-3504 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3504): The (1) serf_ssl_cert_issuer, (2) serf_ssl_cert_subject, and (3) serf_ssl_cert_certificate functions in Serf 0.2.0 through 1.3.x before 1.3.7 does not properly handle a NUL byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority.
ppc64 stable. Maintainer(s), please cleanup. Security, please vote.
Deletion of <net-libs/serf-1.3.7 is potentially waiting for bug #488434 :( .
Arches, Thank you for your work Maintainer(s), please drop the vulnerable version. GLSA Vote: Yes Blocker set for Bug #488434
Vulnerable <net-libs/serf-1.3.8 dropped.
Arches and Maintainer(s), Thank you for your work.
GLSA Vote: Yes, new request filed
This issue was resolved and addressed in GLSA 201610-05 at https://security.gentoo.org/glsa/201610-05 by GLSA coordinator Aaron Bauman (b-man).