Vulnerability-Lookup

GSD-2020-15134

Vulnerability from gsd - Updated: 2020-07-31 00:00

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

Aliases

CVE-2020-15134

JSON

To clipboard

{
  "GSD": {
    "alias": "CVE-2020-15134",
    "description": "Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine 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 is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory.",
    "id": "GSD-2020-15134"
  },
  "gsd": {
    "metadata": {
      "exploitCode": "unknown",
      "remediation": "unknown",
      "reportConfidence": "confirmed",
      "type": "vulnerability"
    },
    "osvSchema": {
      "affected": [
        {
          "package": {
            "ecosystem": "RubyGems",
            "name": "faye",
            "purl": "pkg:gem/faye"
          }
        }
      ],
      "aliases": [
        "CVE-2020-15134",
        "GHSA-3q49-h8f9-9fr9"
      ],
      "details": "Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of\nits client. Those libraries both use the [`EM::Connection#start_tls`][1] method\nin [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is\nused for the connection. This method does not implement certificate verification\nby default, meaning that it does not check that the server presents a valid and\ntrusted TLS certificate for the expected hostname. That means that any `https:`\nor `wss:` connection made using these libraries is vulnerable to a\nman-in-the-middle attack, since it does not confirm the identity of the server\nit is connected to.\n\nThe first request a Faye client makes is always sent via normal HTTP, but later\nmessages may be sent via WebSocket. Therefore it is vulnerable to the same\nproblem that these underlying libraries are, and we needed both libraries to\nsupport TLS verification before Faye could claim to do the same. Your client\nwould still be insecure if its initial HTTPS request was verified, but later\nWebSocket connections were not.\n\nThis has been a requested feature in EventMachine for many years now; see for\nexample [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request\npublished an [advisory][7] related to this problem and fixed it by [implementing\nTLS verification][8] in their own codebase; although EventMachine does not\nimplement certificate verification itself, it provides an extension point for\nthe caller to implement it, called [`ssl_verify_peer`][9]. Based on this\nimplementation, we have incorporated similar functionality into faye-websocket.\n\nAfter implementing verification in v1.1.6, em-http-request has elected to leave\nthe `:verify_peer` option switched off by default. We have decided to _enable_\nthis option by default in Faye, but are publishing a minor release with added\nfunctionality for configuring it. We are mindful of the fact that this may break\nexisting programs, but we consider it much more important that all clients have\nTLS verification turned on by default. A client that is not carrying out\nverification 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\nself-signed certificate. We consider this use case to be \"working by accident\",\nrather than functionality that was actively supported, and it should be properly\nand explicitly supported instead.\n\nWe are releasing Faye v1.4.0, which enables verification by default and provides\na way to opt out of it:\n\n```rb\nclient = Faye::Client.new(\u0027https://example.com/\u0027, tls: { verify_peer: false })\n```\n\nUnfortunately we can\u0027t offer an equivalent of the `:root_cert_file` option that\nhas been added to faye-websocket, because em-http-request does not support it.\nIf you need to talk to servers whose certificates are not recognised by your\ndefault root certificates, then you need to add its certificate (or another one\nthat can verify it) to your system\u0027s root set.\n\nThe same functionality is now supported in the Node.js version, with a `tls`\noption whose values will be passed to the `https` and `tls` modules as\nappropriate when making connections. For example, you can provide your own CA\ncertificate:\n\n```js\nvar client = new faye.Client(\u0027https://example.com/\u0027, {\n  tls: {\n    ca: fs.readFileSync(\u0027path/to/certificate.pem\u0027)\n  }\n});\n```\n\nFor further background information on this issue, please see [faye#524][12] and\n[faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel\nMorsing][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",
      "id": "GSD-2020-15134",
      "modified": "2020-07-31T00:00:00.000Z",
      "published": "2020-07-31T00:00:00.000Z",
      "references": [
        {
          "type": "WEB",
          "url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
        }
      ],
      "schema_version": "1.4.0",
      "severity": [
        {
          "score": 8.0,
          "type": "CVSS_V3"
        }
      ],
      "summary": "Missing TLS certificate verification"
    }
  },
  "namespaces": {
    "cve.org": {
      "CVE_data_meta": {
        "ASSIGNER": "security-advisories@github.com",
        "ID": "CVE-2020-15134",
        "STATE": "PUBLIC",
        "TITLE": "Missing TLS certificate verification in Faye"
      },
      "affects": {
        "vendor": {
          "vendor_data": [
            {
              "product": {
                "product_data": [
                  {
                    "product_name": "faye",
                    "version": {
                      "version_data": [
                        {
                          "version_value": "\u003c 1.4.0"
                        }
                      ]
                    }
                  }
                ]
              },
              "vendor_name": "faye"
            }
          ]
        }
      },
      "data_format": "MITRE",
      "data_type": "CVE",
      "data_version": "4.0",
      "description": {
        "description_data": [
          {
            "lang": "eng",
            "value": "Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine 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 is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory."
          }
        ]
      },
      "impact": {
        "cvss": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "CHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
          "version": "3.1"
        }
      },
      "problemtype": {
        "problemtype_data": [
          {
            "description": [
              {
                "lang": "eng",
                "value": "CWE-295: Improper Certificate Validation"
              }
            ]
          }
        ]
      },
      "references": {
        "reference_data": [
          {
            "name": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9",
            "refsource": "CONFIRM",
            "url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
          },
          {
            "name": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/",
            "refsource": "MISC",
            "url": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/"
          }
        ]
      },
      "source": {
        "advisory": "GHSA-3q49-h8f9-9fr9",
        "discovery": "UNKNOWN"
      }
    },
    "github.com/rubysec/ruby-advisory-db": {
      "cve": "2020-15134",
      "cvss_v3": 8.0,
      "date": "2020-07-31",
      "description": "Faye uses [em-http-request][6] and [faye-websocket][10] in the Ruby version of\nits client. Those libraries both use the [`EM::Connection#start_tls`][1] method\nin [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL is\nused for the connection. This method does not implement certificate verification\nby default, meaning that it does not check that the server presents a valid and\ntrusted TLS certificate for the expected hostname. That means that any `https:`\nor `wss:` connection made using these libraries is vulnerable to a\nman-in-the-middle attack, since it does not confirm the identity of the server\nit is connected to.\n\nThe first request a Faye client makes is always sent via normal HTTP, but later\nmessages may be sent via WebSocket. Therefore it is vulnerable to the same\nproblem that these underlying libraries are, and we needed both libraries to\nsupport TLS verification before Faye could claim to do the same. Your client\nwould still be insecure if its initial HTTPS request was verified, but later\nWebSocket connections were not.\n\nThis has been a requested feature in EventMachine for many years now; see for\nexample [#275][3], [#378][4], and [#814][5]. In June 2020, em-http-request\npublished an [advisory][7] related to this problem and fixed it by [implementing\nTLS verification][8] in their own codebase; although EventMachine does not\nimplement certificate verification itself, it provides an extension point for\nthe caller to implement it, called [`ssl_verify_peer`][9]. Based on this\nimplementation, we have incorporated similar functionality into faye-websocket.\n\nAfter implementing verification in v1.1.6, em-http-request has elected to leave\nthe `:verify_peer` option switched off by default. We have decided to _enable_\nthis option by default in Faye, but are publishing a minor release with added\nfunctionality for configuring it. We are mindful of the fact that this may break\nexisting programs, but we consider it much more important that all clients have\nTLS verification turned on by default. A client that is not carrying out\nverification 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\nself-signed certificate. We consider this use case to be \"working by accident\",\nrather than functionality that was actively supported, and it should be properly\nand explicitly supported instead.\n\nWe are releasing Faye v1.4.0, which enables verification by default and provides\na way to opt out of it:\n\n```rb\nclient = Faye::Client.new(\u0027https://example.com/\u0027, tls: { verify_peer: false })\n```\n\nUnfortunately we can\u0027t offer an equivalent of the `:root_cert_file` option that\nhas been added to faye-websocket, because em-http-request does not support it.\nIf you need to talk to servers whose certificates are not recognised by your\ndefault root certificates, then you need to add its certificate (or another one\nthat can verify it) to your system\u0027s root set.\n\nThe same functionality is now supported in the Node.js version, with a `tls`\noption whose values will be passed to the `https` and `tls` modules as\nappropriate when making connections. For example, you can provide your own CA\ncertificate:\n\n```js\nvar client = new faye.Client(\u0027https://example.com/\u0027, {\n  tls: {\n    ca: fs.readFileSync(\u0027path/to/certificate.pem\u0027)\n  }\n});\n```\n\nFor further background information on this issue, please see [faye#524][12] and\n[faye-websocket#129][13]. We would like to thank [Tero Marttila][14] and [Daniel\nMorsing][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",
      "gem": "faye",
      "ghsa": "3q49-h8f9-9fr9",
      "patched_versions": [
        "\u003e= 1.4.0"
      ],
      "title": "Missing TLS certificate verification",
      "url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
    },
    "gitlab.com": {
      "advisories": [
        {
          "affected_range": "\u003c1.4.0",
          "affected_versions": "All versions before 1.4.0",
          "cvss_v2": "AV:N/AC:L/Au:N/C:P/I:P/A:N",
          "cvss_v3": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
          "cwe_ids": [
            "CWE-1035",
            "CWE-295",
            "CWE-937"
          ],
          "date": "2020-08-11",
          "description": "In faye-websocket, there is a lack of certification validation in TLS handshakes. The `Faye::WebSocket::Client` class uses the `EM::Connection#start_tls` method in `EventMachine` 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 `wss:` connection made using this library is vulnerable to a man-in-the-middle attack.",
          "fixed_versions": [
            "1.4.0"
          ],
          "identifier": "CVE-2020-15134",
          "identifiers": [
            "CVE-2020-15134",
            "GHSA-3q49-h8f9-9fr9"
          ],
          "not_impacted": "All versions starting from 1.4.0",
          "package_slug": "gem/faye",
          "pubdate": "2020-07-31",
          "solution": "Upgrade to version 1.4.0 or above.",
          "title": "Improper Certificate Validation",
          "urls": [
            "https://nvd.nist.gov/vuln/detail/CVE-2020-15134"
          ],
          "uuid": "7a30778b-02c3-4f80-b34c-851475bb5a5f"
        }
      ]
    },
    "nvd.nist.gov": {
      "configurations": {
        "CVE_data_version": "4.0",
        "nodes": [
          {
            "children": [],
            "cpe_match": [
              {
                "cpe23Uri": "cpe:2.3:a:faye_project:faye:*:*:*:*:*:*:*:*",
                "cpe_name": [],
                "versionEndExcluding": "1.4.0",
                "vulnerable": true
              }
            ],
            "operator": "OR"
          }
        ]
      },
      "cve": {
        "CVE_data_meta": {
          "ASSIGNER": "security-advisories@github.com",
          "ID": "CVE-2020-15134"
        },
        "data_format": "MITRE",
        "data_type": "CVE",
        "data_version": "4.0",
        "description": {
          "description_data": [
            {
              "lang": "en",
              "value": "Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine 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 is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory."
            }
          ]
        },
        "problemtype": {
          "problemtype_data": [
            {
              "description": [
                {
                  "lang": "en",
                  "value": "CWE-295"
                }
              ]
            }
          ]
        },
        "references": {
          "reference_data": [
            {
              "name": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/",
              "refsource": "MISC",
              "tags": [
                "Exploit",
                "Third Party Advisory"
              ],
              "url": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/"
            },
            {
              "name": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9",
              "refsource": "CONFIRM",
              "tags": [
                "Exploit",
                "Third Party Advisory"
              ],
              "url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9"
            }
          ]
        }
      },
      "impact": {
        "baseMetricV2": {
          "acInsufInfo": true,
          "cvssV2": {
            "accessComplexity": "LOW",
            "accessVector": "NETWORK",
            "authentication": "NONE",
            "availabilityImpact": "NONE",
            "baseScore": 6.4,
            "confidentialityImpact": "PARTIAL",
            "integrityImpact": "PARTIAL",
            "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N",
            "version": "2.0"
          },
          "exploitabilityScore": 10.0,
          "impactScore": 4.9,
          "obtainAllPrivilege": false,
          "obtainOtherPrivilege": false,
          "obtainUserPrivilege": false,
          "severity": "MEDIUM",
          "userInteractionRequired": false
        },
        "baseMetricV3": {
          "cvssV3": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N",
            "version": "3.1"
          },
          "exploitabilityScore": 2.2,
          "impactScore": 5.8
        }
      },
      "lastModifiedDate": "2020-08-11T17:15Z",
      "publishedDate": "2020-07-31T18:15Z"
    }
  }
}

GHSA-3Q49-H8F9-9FR9

Vulnerability from github – Published: 2020-07-31 17:39 – Updated: 2023-05-16 16:03

Summary

Missing TLS certificate verification

Details

Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the EM::Connection#start_tls method in EventMachine 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, #378, and #814. In June 2020, em-http-request published an advisory related to this problem and fixed it by implementing TLS verification 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. 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:

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:

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 and faye-websocket#129. We would like to thank Tero Marttila and Daniel Morsing for providing invaluable assistance and feedback on this issue.

Severity ?

8.0 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "faye"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-15134"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-07-31T17:38:46Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "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(\u0027https://example.com/\u0027, tls: { verify_peer: false })\n```\n\nUnfortunately we can\u0027t 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\u0027s 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(\u0027https://example.com/\u0027, {\n  tls: {\n    ca: fs.readFileSync(\u0027path/to/certificate.pem\u0027)\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",
  "id": "GHSA-3q49-h8f9-9fr9",
  "modified": "2023-05-16T16:03:45Z",
  "published": "2020-07-31T17:39:42Z",
  "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Missing TLS certificate verification"
}

CVE-2020-15134 (GCVE-0-2020-15134)

Vulnerability from cvelistv5 – Published: 2020-07-31 17:40 – Updated: 2024-08-04 13:08

Title

Missing TLS certificate verification in Faye

Summary

Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine 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 is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory.

Severity ?

8 (High)


                        
                          CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N

CWE

CWE-295 - Improper Certificate Validation

Assigner

GitHub_M

References

URL

	Vendor	Product	Version
	faye	faye	Affected: < 1.4.0

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GSD-2020-15134

GHSA-3Q49-H8F9-9FR9

CVE-2020-15134 (GCVE-0-2020-15134)

Tags

Sightings

Nomenclature