GSD-2020-15133
Vulnerability from gsd - Updated: 2020-07-31 00:00Details
The `Faye::WebSocket::Client` class uses 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 `wss:` connection made using this library is vulnerable to a
man-in-the-middle attack, since it does not confirm the identity of the server
it is connected to.
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][6]
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
for Ruby][10], such that we use the `OpenSSL` module to perform two checks:
- The chain of certificates presented by the server is valid and ultimately
trusted by your root certificate set -- either your system default root
certificates, or a set provided at runtime
- The final certificate presented by the server is valid for the hostname used
in the request URI; if the connection is made via a proxy we use the hostname
from the request, not the proxy's hostname
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-websocket, 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. To that end, we have added two new options to
the `Faye::WebSocket::Client` constructor: `tls.root_cert_file`, and
`tls.verify_peer`.
The `:root_cert_file` option lets you provide a different set of root
certificates in situations where you don't want to use your system's default
root certificates to verify the remote host. It should be a path or an array of
paths identifying the certificates to use instead of the defaults.
```rb
client = Faye::WebSocket::Client.new('wss://example.com/', [], tls: {
root_cert_file: 'path/to/certificate.pem'
})
```
The `:verify_peer` option lets you turn verification off entirely. This should
be a last resort and we recommend using the `:root_cert_file` option if
possible.
```rb
client = Faye::WebSocket::Client.new('wss://example.com/', [], tls: {
verify_peer: false
})
```
To get the new behaviour, please upgrade to v0.11.0 of the [Rubygems
package][10]. There are, unfortunately, no workarounds for this issue, as you
cannot enable `:verify_peer` in EventMachine unless the calling library contains
an implementation of `ssl_verify_peer` that actually checks the server's
certificates.
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
[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
Aliases
{
"GSD": {
"alias": "CVE-2020-15133",
"description": "In faye-websocket before version 0.11.0, 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, since it does not confirm the identity of the server it is connected to. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended.",
"id": "GSD-2020-15133"
},
"gsd": {
"metadata": {
"exploitCode": "unknown",
"remediation": "unknown",
"reportConfidence": "confirmed",
"type": "vulnerability"
},
"osvSchema": {
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "faye-websocket",
"purl": "pkg:gem/faye-websocket"
}
}
],
"aliases": [
"CVE-2020-15133",
"GHSA-2v5c-755p-p4gv"
],
"details": "The `Faye::WebSocket::Client` class uses the [`EM::Connection#start_tls`][1]\nmethod in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL\nis used for the connection. This method does not implement certificate\nverification by default, meaning that it does not check that the server presents\na valid and trusted TLS certificate for the expected hostname. That means that\nany `wss:` connection made using this library is vulnerable to a\nman-in-the-middle attack, since it does not confirm the identity of the server\nit is connected to.\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][6]\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\nfor Ruby][10], such that we use the `OpenSSL` module to perform two checks:\n\n- The chain of certificates presented by the server is valid and ultimately\n trusted by your root certificate set -- either your system default root\n certificates, or a set provided at runtime\n- The final certificate presented by the server is valid for the hostname used\n in the request URI; if the connection is made via a proxy we use the hostname\n from the request, not the proxy\u0027s hostname\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-websocket, but are publishing a minor release\nwith added functionality for configuring it. We are mindful of the fact that\nthis may break existing programs, but we consider it much more important that\nall clients have TLS verification turned on by default. A client that is not\ncarrying 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\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. To that end, we have added two new options to\nthe `Faye::WebSocket::Client` constructor: `tls.root_cert_file`, and\n`tls.verify_peer`.\n\nThe `:root_cert_file` option lets you provide a different set of root\ncertificates in situations where you don\u0027t want to use your system\u0027s default\nroot certificates to verify the remote host. It should be a path or an array of\npaths identifying the certificates to use instead of the defaults.\n\n```rb\nclient = Faye::WebSocket::Client.new(\u0027wss://example.com/\u0027, [], tls: {\n root_cert_file: \u0027path/to/certificate.pem\u0027\n})\n```\n\nThe `:verify_peer` option lets you turn verification off entirely. This should\nbe a last resort and we recommend using the `:root_cert_file` option if\npossible.\n\n```rb\nclient = Faye::WebSocket::Client.new(\u0027wss://example.com/\u0027, [], tls: {\n verify_peer: false\n})\n```\n\nTo get the new behaviour, please upgrade to v0.11.0 of the [Rubygems\npackage][10]. There are, unfortunately, no workarounds for this issue, as you\ncannot enable `:verify_peer` in EventMachine unless the calling library contains\nan implementation of `ssl_verify_peer` that actually checks the server\u0027s\ncertificates.\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[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-15133",
"modified": "2020-07-31T00:00:00.000Z",
"published": "2020-07-31T00:00:00.000Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": 8.0,
"type": "CVSS_V3"
}
],
"summary": "Missing TLS certificate verification in faye-websocket"
}
},
"namespaces": {
"cve.org": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2020-15133",
"STATE": "PUBLIC",
"TITLE": "Missing TLS certificate verification in Faye Websocket"
},
"affects": {
"vendor": {
"vendor_data": [
{
"product": {
"product_data": [
{
"product_name": "faye-websocket",
"version": {
"version_data": [
{
"version_value": "\u003c 0.11.0"
}
]
}
}
]
},
"vendor_name": "faye"
}
]
}
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "eng",
"value": "In faye-websocket before version 0.11.0, 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, since it does not confirm the identity of the server it is connected to. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended."
}
]
},
"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://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/"
},
{
"name": "https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv",
"refsource": "CONFIRM",
"url": "https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv"
}
]
},
"source": {
"advisory": "GHSA-2v5c-755p-p4gv",
"discovery": "UNKNOWN"
}
},
"github.com/rubysec/ruby-advisory-db": {
"cve": "2020-15133",
"cvss_v3": 8.0,
"date": "2020-07-31",
"description": "The `Faye::WebSocket::Client` class uses the [`EM::Connection#start_tls`][1]\nmethod in [EventMachine][2] to implement the TLS handshake whenever a `wss:` URL\nis used for the connection. This method does not implement certificate\nverification by default, meaning that it does not check that the server presents\na valid and trusted TLS certificate for the expected hostname. That means that\nany `wss:` connection made using this library is vulnerable to a\nman-in-the-middle attack, since it does not confirm the identity of the server\nit is connected to.\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][6]\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\nfor Ruby][10], such that we use the `OpenSSL` module to perform two checks:\n\n- The chain of certificates presented by the server is valid and ultimately\n trusted by your root certificate set -- either your system default root\n certificates, or a set provided at runtime\n- The final certificate presented by the server is valid for the hostname used\n in the request URI; if the connection is made via a proxy we use the hostname\n from the request, not the proxy\u0027s hostname\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-websocket, but are publishing a minor release\nwith added functionality for configuring it. We are mindful of the fact that\nthis may break existing programs, but we consider it much more important that\nall clients have TLS verification turned on by default. A client that is not\ncarrying 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\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. To that end, we have added two new options to\nthe `Faye::WebSocket::Client` constructor: `tls.root_cert_file`, and\n`tls.verify_peer`.\n\nThe `:root_cert_file` option lets you provide a different set of root\ncertificates in situations where you don\u0027t want to use your system\u0027s default\nroot certificates to verify the remote host. It should be a path or an array of\npaths identifying the certificates to use instead of the defaults.\n\n```rb\nclient = Faye::WebSocket::Client.new(\u0027wss://example.com/\u0027, [], tls: {\n root_cert_file: \u0027path/to/certificate.pem\u0027\n})\n```\n\nThe `:verify_peer` option lets you turn verification off entirely. This should\nbe a last resort and we recommend using the `:root_cert_file` option if\npossible.\n\n```rb\nclient = Faye::WebSocket::Client.new(\u0027wss://example.com/\u0027, [], tls: {\n verify_peer: false\n})\n```\n\nTo get the new behaviour, please upgrade to v0.11.0 of the [Rubygems\npackage][10]. There are, unfortunately, no workarounds for this issue, as you\ncannot enable `:verify_peer` in EventMachine unless the calling library contains\nan implementation of `ssl_verify_peer` that actually checks the server\u0027s\ncertificates.\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[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-websocket",
"ghsa": "2v5c-755p-p4gv",
"patched_versions": [
"\u003e= 0.11.0"
],
"title": "Missing TLS certificate verification in faye-websocket",
"url": "https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv"
},
"gitlab.com": {
"advisories": [
{
"affected_range": "\u003c0.11.0",
"affected_versions": "All versions before 0.11.0",
"cvss_v2": "AV:N/AC:M/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, since it does not confirm the identity of the server it is connected to.",
"fixed_versions": [
"0.11.0"
],
"identifier": "CVE-2020-15133",
"identifiers": [
"CVE-2020-15133",
"GHSA-2v5c-755p-p4gv"
],
"not_impacted": "All versions starting from 0.11.0",
"package_slug": "gem/faye-websocket",
"pubdate": "2020-07-31",
"solution": "Upgrade to version 0.11.0 or above.",
"title": "Improper Certificate Validation",
"urls": [
"https://nvd.nist.gov/vuln/detail/CVE-2020-15133",
"https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/",
"https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv"
],
"uuid": "d84a708f-7a94-4215-b5f2-733e0f4126e5"
}
]
},
"nvd.nist.gov": {
"configurations": {
"CVE_data_version": "4.0",
"nodes": [
{
"children": [],
"cpe_match": [
{
"cpe23Uri": "cpe:2.3:a:faye-websocket_project:faye-websocket:*:*:*:*:*:*:*:*",
"cpe_name": [],
"versionEndExcluding": "0.11.0",
"vulnerable": true
}
],
"operator": "OR"
}
]
},
"cve": {
"CVE_data_meta": {
"ASSIGNER": "security-advisories@github.com",
"ID": "CVE-2020-15133"
},
"data_format": "MITRE",
"data_type": "CVE",
"data_version": "4.0",
"description": {
"description_data": [
{
"lang": "en",
"value": "In faye-websocket before version 0.11.0, 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, since it does not confirm the identity of the server it is connected to. For further background information on this issue, please see the referenced GitHub Advisory. Upgrading `faye-websocket` to v0.11.0 is recommended."
}
]
},
"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-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv",
"refsource": "CONFIRM",
"tags": [
"Exploit",
"Third Party Advisory"
],
"url": "https://github.com/faye/faye-websocket-ruby/security/advisories/GHSA-2v5c-755p-p4gv"
}
]
}
},
"impact": {
"baseMetricV2": {
"acInsufInfo": false,
"cvssV2": {
"accessComplexity": "MEDIUM",
"accessVector": "NETWORK",
"authentication": "NONE",
"availabilityImpact": "NONE",
"baseScore": 5.8,
"confidentialityImpact": "PARTIAL",
"integrityImpact": "PARTIAL",
"vectorString": "AV:N/AC:M/Au:N/C:P/I:P/A:N",
"version": "2.0"
},
"exploitabilityScore": 8.6,
"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": "2021-11-18T18:28Z",
"publishedDate": "2020-07-31T18:15Z"
}
}
}
Loading…
Loading…
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.
Loading…
Loading…