Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 519202 (CVE-2014-3504) - <dev-vcs/subversion-{1.7.18,1.8.10}, <net-libs/serf-1.3.7: Man-in-the-middle vulnerability, hash collisions (CVE-2014-{3504,3522,3528})
Summary: <dev-vcs/subversion-{1.7.18,1.8.10}, <net-libs/serf-1.3.7: Man-in-the-middle ...
Status: RESOLVED FIXED
Alias: CVE-2014-3504
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: B3 [glsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-06 12:33 UTC by Chris Reffett (RETIRED)
Modified: 2016-10-11 12:47 UTC (History)
4 users (show)

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


Attachments
serf CVE-2014-3504 patch (serf-cve-2014-3504.patch,10.03 KB, patch)
2014-08-06 12:33 UTC, Chris Reffett (RETIRED)
no flags Details | Diff
Subversion CVE-2014-2522 patch (subversion-cve-2014-2522.patch,32.63 KB, patch)
2014-08-06 12:34 UTC, Chris Reffett (RETIRED)
no flags Details | Diff
Subversion CVE-2014-3528 patch (subversion-cve-2014-3528.patch,2.09 KB, patch)
2014-08-06 12:35 UTC, Chris Reffett (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Reffett (RETIRED) gentoo-dev Security 2014-08-06 12:33:18 UTC
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)
}}}
Comment 1 Chris Reffett (RETIRED) gentoo-dev Security 2014-08-06 12:34:46 UTC
Created attachment 382376 [details, diff]
Subversion CVE-2014-2522 patch
Comment 2 Chris Reffett (RETIRED) gentoo-dev Security 2014-08-06 12:35:09 UTC
Created attachment 382378 [details, diff]
Subversion CVE-2014-3528 patch
Comment 3 Mike Gilbert gentoo-dev 2014-08-07 05:57:01 UTC
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.
Comment 4 Sergey Popov gentoo-dev 2014-08-07 07:17:16 UTC
(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
Comment 5 Lars Wendler (Polynomial-C) (RETIRED) gentoo-dev 2014-08-12 11:07:52 UTC
+*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
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2014-08-13 12:08:57 UTC
What happened to 1.7.18? Is 1.7.* on its way out after stabilisation?
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2014-08-13 12:10:21 UTC
Stable for HPPA.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2014-08-13 12:22:30 UTC
Wait, what happened to net-libs/serf?
Comment 9 Thomas Sachau gentoo-dev 2014-08-14 17:03:17 UTC
(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"
Comment 10 Agostino Sarubbo gentoo-dev 2014-08-19 06:43:20 UTC
amd64 stable
Comment 11 Agostino Sarubbo gentoo-dev 2014-08-19 06:44:08 UTC
x86 stable
Comment 12 Raúl Porcel (RETIRED) gentoo-dev 2014-08-19 10:41:23 UTC
alpha/arm/arm64/ia64/sparc stable
Comment 13 Sergey Popov gentoo-dev 2014-08-19 10:54:49 UTC
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
Comment 14 Jeroen Roovers (RETIRED) gentoo-dev 2014-08-19 20:22:34 UTC
Stable for HPPA.
Comment 15 Raúl Porcel (RETIRED) gentoo-dev 2014-08-20 11:41:27 UTC
alpha/arm/arm64/ia64/sparc/x86 stable
Comment 16 Agostino Sarubbo gentoo-dev 2014-08-20 15:50:07 UTC
amd64 stable
Comment 17 Agostino Sarubbo gentoo-dev 2014-08-21 09:49:39 UTC
ppc stable
Comment 18 GLSAMaker/CVETool Bot gentoo-dev 2014-08-25 16:12:53 UTC
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.
Comment 19 Agostino Sarubbo gentoo-dev 2014-08-30 17:02:48 UTC
ppc64 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 20 Arfrever Frehtes Taifersar Arahesis 2014-08-31 08:14:31 UTC
Deletion of <net-libs/serf-1.3.7 is potentially waiting for bug #488434 :( .
Comment 21 Yury German Gentoo Infrastructure gentoo-dev 2014-09-09 19:30:08 UTC
Arches, Thank you for your work
Maintainer(s), please drop the vulnerable version.

GLSA Vote: Yes

Blocker set for Bug #488434
Comment 22 Arfrever Frehtes Taifersar Arahesis 2015-01-13 22:17:45 UTC
Vulnerable <net-libs/serf-1.3.8 dropped.
Comment 23 Yury German Gentoo Infrastructure gentoo-dev 2015-04-22 21:15:39 UTC
Arches and Maintainer(s), Thank you for your work.
Comment 24 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-05-11 16:09:16 UTC
GLSA Vote: Yes, new request filed
Comment 25 GLSAMaker/CVETool Bot gentoo-dev 2016-10-11 12:47:15 UTC
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).