Attachment 924402 Details for Bug 1127063 – Upstream advisory draft

Upstream advisory draft

CVE-2014-3522-advisory.txt (text/plain), 5.78 KB, created by Tomas Hoger on 2014-08-06 08:43:28 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Tomas Hoger

Created: 2014-08-06 08:43:28 UTC

Size: 5.78 KB

patch

obsolete

>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
>

Actions: View

Attachments on bug 1127063: 924402 | 924403 | 924404