CVE-2020-15134: Faye Missing TLS Certificate Verification Vulnerability

HIGH
Advisory Identifier: GHSA-3q49-h8f9-9fr9
CVSS 8.0
CWE-295
Published
Advisory Summary

CVE-2020-15134 is a HIGH (CVSS 8.0) missing tls certificate verification vulnerability (CWE-295: Improper Certificate Validation) affecting Faye libraries in the RubyGems ecosystem. The issue involves missing tls certificate verification. Remediation is available by upgrading affected packages to version 1.4.0.

CVE-2020-15134 at a Glance

CVE Identifier CVE-2020-15134
GHSA Identifier GHSA-3q49-h8f9-9fr9
Severity HIGH
CVSS v3.1 Base Score 8.0
CWE Classification CWE-295: Improper Certificate Validation
Affected Product Faye
Package Ecosystem RubyGems
Published Date
Last Updated

Security Impact

CVSS: 8.0

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction Required (UI:R)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2020-15134

To remediate this vulnerability, upgrade all affected Faye dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

faye fixed: 1.4.0
Upgrade faye to 1.4.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for faye

How to Check if You Are Affected

To determine whether your application is affected by CVE-2020-15134, inspect your project dependencies for Faye:

inspect dependencies for faye

Analyze the terminal output to locate any version of Faye in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.4.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-295: Improper Certificate Validation, where the product does not validate, or incorrectly validates, a certificate. In Faye, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of its client. Those libraries both use the [`EM::Connection#start_tls`][1] method in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This has been a requested feature in EventMachine for many years now; see for example [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request published an [advisory][7] related to this problem and fixed it by [implementing TLS verification][8] in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for the caller to implement it, called [`ssl_verify_peer`][9]. Based on this implementation, we have incorporated similar functionality into faye-websocket. After implementing verification in v1.1.6, em-http-request has elected to leave the `:verify_peer` option switched off by default. We have decided to _enable_ this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either: - talking to the expected server, and will not break under this change - being attacked, and would benefit from being alerted to this fact - deliberately talking to a server that would be rejected by verification The latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be "working by accident", rather than functionality that was actively supported, and it should be properly and explicitly supported instead. We are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it: ```rb client = Faye::Client.new('https://example.com/', tls: { verify_peer: false }) ``` Unfortunately we can't offer an equivalent of the `:root_cert_file` option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set. The same functionality is now supported in the Node.js version, with a `tls` option whose values will be passed to the `https` and `tls` modules as appropriate when making connections. For example, you can provide your own CA certificate: ```js var client = new faye.Client('https://example.com/', { tls: { ca: fs.readFileSync('path/to/certificate.pem') } }); ``` For further background information on this issue, please see [faye#524][12] and [faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel Morsing][15] for providing invaluable assistance and feedback on this issue. [1]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls [2]: https://rubygems.org/gems/eventmachine [3]: https://github.com/eventmachine/eventmachine/issues/275 [4]: https://github.com/eventmachine/eventmachine/pull/378 [5]: https://github.com/eventmachine/eventmachine/issues/814 [6]: https://rubygems.org/gems/em-http-request [7]: https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request [8]: https://github.com/igrigorik/em-http-request/pull/340 [9]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer [10]: https://rubygems.org/gems/faye-websocket [11]: https://faye.jcoglan.com/ [12]: https://github.com/faye/faye/issues/524 [13]: https://github.com/faye/faye-websocket-ruby/pull/129 [14]: https://github.com/SpComb [15]: https://github.com/DanielMorsing

CVE-2020-15134 Affected Faye Versions

1 component(s)
Fixed Versions:
1.4.0
Product / Package Ecosystem Affected Versions Fixed Version
faye
RubyGems
< 1.4.0
1.4.0

References

Frequently Asked Questions

What is CVE-2020-15134?
CVE-2020-15134 is a security vulnerability in Faye involving Missing TLS certificate verification under CWE-295: Improper Certificate Validation.
Which Faye versions are affected?
Affected versions include releases prior to 1.4.0 across affected packages: faye.
What version fixes CVE-2020-15134?
Upgrading to 1.4.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is faye affected?
Yes, faye is affected in releases prior to 1.4.0. Upgrade your dependency to 1.4.0 or later.
What is the CVSS score of CVE-2020-15134?
CVE-2020-15134 has a CVSS v3.1 base score of 8.0 (HIGH) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N.
What CWE is associated with CVE-2020-15134?
CVE-2020-15134 is classified under CWE-295: Improper Certificate Validation (The product does not validate, or incorrectly validates, a certificate.).
How can I check RubyGems dependencies for CVE-2020-15134?
Run the dependency tree command: 'inspect dependencies for faye'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3q49-h8f9-9fr9",
  "modified" : "2023-05-16T16:03:45Z",
  "published" : "2020-07-31T17:39:42Z",
  "aliases" : [ "CVE-2020-15134" ],
  "summary" : "Missing TLS certificate verification",
  "details" : "Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of its client. Those libraries both use the [`EM::Connection#start_tls`][1] method in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to.\n\nThe first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not.\n\nThis has been a requested feature in EventMachine for many years now; see for example [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request published an [advisory][7] related to this problem and fixed it by [implementing TLS verification][8] in their own codebase; although EventMachine does not implement certificate verification itself, it provides an extension point for\nthe caller to implement it, called [`ssl_verify_peer`][9]. Based on this implementation, we have incorporated similar functionality into faye-websocket.\n\nAfter implementing verification in v1.1.6, em-http-request has elected to leave the `:verify_peer` option switched off by default. We have decided to _enable_ this option by default in Faye, but are publishing a minor release with added functionality for configuring it. We are mindful of the fact that this may break existing programs, but we consider it much more important that all clients have TLS verification turned on by default. A client that is not carrying out verification is either:\n\n- talking to the expected server, and will not break under this change\n- being attacked, and would benefit from being alerted to this fact\n- deliberately talking to a server that would be rejected by verification\n\nThe latter case includes situations like talking to a non-public server using a self-signed certificate. We consider this use case to be \"working by accident\", rather than functionality that was actively supported, and it should be properly and explicitly supported instead.\n\nWe are releasing Faye v1.4.0, which enables verification by default and provides a way to opt out of it:\n\n```rb\nclient = Faye::Client.new('https://example.com/', tls: { verify_peer: false })\n```\n\nUnfortunately we can't offer an equivalent of the `:root_cert_file` option that has been added to faye-websocket, because em-http-request does not support it. If you need to talk to servers whose certificates are not recognised by your default root certificates, then you need to add its certificate (or another one that can verify it) to your system's root set.\n\nThe same functionality is now supported in the Node.js version, with a `tls` option whose values will be passed to the `https` and `tls` modules as appropriate when making connections. For example, you can provide your own CA certificate:\n\n```js\nvar client = new faye.Client('https://example.com/', {\n  tls: {\n    ca: fs.readFileSync('path/to/certificate.pem')\n  }\n});\n```\n\nFor further background information on this issue, please see [faye#524][12] and [faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel Morsing][15] for providing invaluable assistance and feedback on this issue.\n\n[1]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls\n[2]: https://rubygems.org/gems/eventmachine\n[3]: https://github.com/eventmachine/eventmachine/issues/275\n[4]: https://github.com/eventmachine/eventmachine/pull/378\n[5]: https://github.com/eventmachine/eventmachine/issues/814\n[6]: https://rubygems.org/gems/em-http-request\n[7]: https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request\n[8]: https://github.com/igrigorik/em-http-request/pull/340\n[9]: https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer\n[10]: https://rubygems.org/gems/faye-websocket\n[11]: https://faye.jcoglan.com/\n[12]: https://github.com/faye/faye/issues/524\n[13]: https://github.com/faye/faye-websocket-ruby/pull/129\n[14]: https://github.com/SpComb\n[15]: https://github.com/DanielMorsing",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "RubyGems",
      "name" : "faye"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.4.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2020-15134"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/eventmachine/eventmachine/issues/275"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/eventmachine/eventmachine/issues/814"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/faye/faye/issues/524"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/eventmachine/eventmachine/pull/378"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/faye/faye-websocket-ruby/pull/129"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/igrigorik/em-http-request/pull/340"
  }, {
    "type" : "WEB",
    "url" : "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/faye/faye"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/faye/CVE-2020-15134.yml"
  }, {
    "type" : "ADVISORY",
    "url" : "https://securitylab.github.com/advisories/GHSL-2020-094-igrigorik-em-http-request"
  }, {
    "type" : "WEB",
    "url" : "https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:ssl_verify_peer"
  }, {
    "type" : "WEB",
    "url" : "https://www.rubydoc.info/github/eventmachine/eventmachine/EventMachine/Connection:start_tls"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-295" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2020-07-31T17:38:46Z",
    "nvd_published_at" : null
  }
}