gsd-2017-3737
Vulnerability from gsd
Modified
2023-12-13 01:21
Details
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.
Aliases
Aliases
{ GSD: { alias: "CVE-2017-3737", description: "OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an \"error state\" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.", id: "GSD-2017-3737", references: [ "https://www.suse.com/security/cve/CVE-2017-3737.html", "https://www.debian.org/security/2017/dsa-4065", "https://access.redhat.com/errata/RHSA-2018:2187", "https://access.redhat.com/errata/RHSA-2018:2186", "https://access.redhat.com/errata/RHSA-2018:2185", "https://access.redhat.com/errata/RHSA-2018:0998", "https://ubuntu.com/security/CVE-2017-3737", "https://advisories.mageia.org/CVE-2017-3737.html", "https://security.archlinux.org/CVE-2017-3737", "https://alas.aws.amazon.com/cve/html/CVE-2017-3737.html", "https://linux.oracle.com/cve/CVE-2017-3737.html", ], }, gsd: { metadata: { exploitCode: "unknown", remediation: "unknown", reportConfidence: "confirmed", type: "vulnerability", }, osvSchema: { aliases: [ "CVE-2017-3737", ], details: "OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an \"error state\" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.", id: "GSD-2017-3737", modified: "2023-12-13T01:21:16.214291Z", schema_version: "1.4.0", }, }, namespaces: { "cve.org": { CVE_data_meta: { ASSIGNER: "openssl-security@openssl.org", DATE_PUBLIC: "2017-12-07T00:00:00", ID: "CVE-2017-3737", STATE: "PUBLIC", }, affects: { vendor: { vendor_data: [ { product: { product_data: [ { product_name: "OpenSSL", version: { version_data: [ { version_value: "1.0.2b-1.0.2m", }, ], }, }, ], }, vendor_name: "OpenSSL Software Foundation", }, ], }, }, data_format: "MITRE", data_type: "CVE", data_version: "4.0", description: { description_data: [ { lang: "eng", value: "OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an \"error state\" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.", }, ], }, problemtype: { problemtype_data: [ { description: [ { lang: "eng", value: "Unauthenticated read/unencrypted write", }, ], }, ], }, references: { reference_data: [ { name: "RHSA-2018:2185", refsource: "REDHAT", url: "https://access.redhat.com/errata/RHSA-2018:2185", }, { name: "RHSA-2018:2186", refsource: "REDHAT", url: "https://access.redhat.com/errata/RHSA-2018:2186", }, { name: "https://github.com/openssl/openssl/commit/898fb884b706aaeb283de4812340bb0bde8476dc", refsource: "CONFIRM", url: "https://github.com/openssl/openssl/commit/898fb884b706aaeb283de4812340bb0bde8476dc", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html", refsource: "CONFIRM", url: "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html", refsource: "CONFIRM", url: "http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html", }, { name: "https://security.netapp.com/advisory/ntap-20180419-0002/", refsource: "CONFIRM", url: "https://security.netapp.com/advisory/ntap-20180419-0002/", }, { name: "FreeBSD-SA-17:12", refsource: "FREEBSD", url: "https://security.FreeBSD.org/advisories/FreeBSD-SA-17:12.openssl.asc", }, { name: "GLSA-201712-03", refsource: "GENTOO", url: "https://security.gentoo.org/glsa/201712-03", }, { name: "1039978", refsource: "SECTRACK", url: "http://www.securitytracker.com/id/1039978", }, { name: "https://www.openssl.org/news/secadv/20171207.txt", refsource: "CONFIRM", url: "https://www.openssl.org/news/secadv/20171207.txt", }, { name: "https://www.digitalmunition.me/2017/12/cve-2017-3737-openssl-security-bypass-vulnerability/", refsource: "MISC", url: "https://www.digitalmunition.me/2017/12/cve-2017-3737-openssl-security-bypass-vulnerability/", }, { name: "RHSA-2018:0998", refsource: "REDHAT", url: "https://access.redhat.com/errata/RHSA-2018:0998", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html", refsource: "CONFIRM", url: "http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html", }, { name: "DSA-4065", refsource: "DEBIAN", url: "https://www.debian.org/security/2017/dsa-4065", }, { name: "https://cert-portal.siemens.com/productcert/pdf/ssa-179516.pdf", refsource: "CONFIRM", url: "https://cert-portal.siemens.com/productcert/pdf/ssa-179516.pdf", }, { name: "102103", refsource: "BID", url: "http://www.securityfocus.com/bid/102103", }, { name: "https://www.tenable.com/security/tns-2017-16", refsource: "CONFIRM", url: "https://www.tenable.com/security/tns-2017-16", }, { name: "RHSA-2018:2187", refsource: "REDHAT", url: "https://access.redhat.com/errata/RHSA-2018:2187", }, { name: "https://security.netapp.com/advisory/ntap-20180117-0002/", refsource: "CONFIRM", url: "https://security.netapp.com/advisory/ntap-20180117-0002/", }, { name: "https://security.netapp.com/advisory/ntap-20171208-0001/", refsource: "CONFIRM", url: "https://security.netapp.com/advisory/ntap-20171208-0001/", }, { name: "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html", refsource: "MISC", url: "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html", }, ], }, }, "nvd.nist.gov": { configurations: { CVE_data_version: "4.0", nodes: [ { children: [], cpe_match: [ { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2c:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2d:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2e:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2l:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2m:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2b:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2j:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2k:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2h:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2i:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2f:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, { cpe23Uri: "cpe:2.3:a:openssl:openssl:1.0.2g:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, ], operator: "OR", }, { children: [], cpe_match: [ { cpe23Uri: "cpe:2.3:o:debian:debian_linux:9.0:*:*:*:*:*:*:*", cpe_name: [], vulnerable: true, }, ], operator: "OR", }, ], }, cve: { CVE_data_meta: { ASSIGNER: "openssl-security@openssl.org", ID: "CVE-2017-3737", }, data_format: "MITRE", data_type: "CVE", data_version: "4.0", description: { description_data: [ { lang: "en", value: "OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an \"error state\" mechanism. The intent was that if a fatal error occurred during a handshake then OpenSSL would move into the error state and would immediately fail if you attempted to continue the handshake. This works as designed for the explicit handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()), however due to a bug it does not work correctly if SSL_read() or SSL_write() is called directly. In that scenario, if the handshake fails then a fatal error will be returned in the initial function call. If SSL_read()/SSL_write() is subsequently called by the application for the same SSL object then it will succeed and the data is passed without being decrypted/encrypted directly from the SSL/TLS record layer. In order to exploit this issue an application bug would have to be present that resulted in a call to SSL_read()/SSL_write() being issued after having already received a fatal error. OpenSSL version 1.0.2b-1.0.2m are affected. Fixed in OpenSSL 1.0.2n. OpenSSL 1.1.0 is not affected.", }, ], }, problemtype: { problemtype_data: [ { description: [ { lang: "en", value: "CWE-125", }, { lang: "en", value: "CWE-787", }, ], }, ], }, references: { reference_data: [ { name: "https://www.openssl.org/news/secadv/20171207.txt", refsource: "CONFIRM", tags: [ "Vendor Advisory", ], url: "https://www.openssl.org/news/secadv/20171207.txt", }, { name: "1039978", refsource: "SECTRACK", tags: [ "Third Party Advisory", "VDB Entry", ], url: "http://www.securitytracker.com/id/1039978", }, { name: "102103", refsource: "BID", tags: [ "Third Party Advisory", "VDB Entry", ], url: "http://www.securityfocus.com/bid/102103", }, { name: "https://security.netapp.com/advisory/ntap-20171208-0001/", refsource: "CONFIRM", tags: [ "Third Party Advisory", ], url: "https://security.netapp.com/advisory/ntap-20171208-0001/", }, { name: "FreeBSD-SA-17:12", refsource: "FREEBSD", tags: [ "Third Party Advisory", ], url: "https://security.FreeBSD.org/advisories/FreeBSD-SA-17:12.openssl.asc", }, { name: "https://www.digitalmunition.me/2017/12/cve-2017-3737-openssl-security-bypass-vulnerability/", refsource: "MISC", tags: [ "Third Party Advisory", ], url: "https://www.digitalmunition.me/2017/12/cve-2017-3737-openssl-security-bypass-vulnerability/", }, { name: "GLSA-201712-03", refsource: "GENTOO", tags: [ "Third Party Advisory", ], url: "https://security.gentoo.org/glsa/201712-03", }, { name: "DSA-4065", refsource: "DEBIAN", tags: [ "Third Party Advisory", ], url: "https://www.debian.org/security/2017/dsa-4065", }, { name: "https://www.tenable.com/security/tns-2017-16", refsource: "CONFIRM", tags: [], url: "https://www.tenable.com/security/tns-2017-16", }, { name: "https://security.netapp.com/advisory/ntap-20180117-0002/", refsource: "CONFIRM", tags: [], url: "https://security.netapp.com/advisory/ntap-20180117-0002/", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html", refsource: "CONFIRM", tags: [], url: "http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html", }, { name: "https://github.com/openssl/openssl/commit/898fb884b706aaeb283de4812340bb0bde8476dc", refsource: "CONFIRM", tags: [], url: "https://github.com/openssl/openssl/commit/898fb884b706aaeb283de4812340bb0bde8476dc", }, { name: "RHSA-2018:0998", refsource: "REDHAT", tags: [], url: "https://access.redhat.com/errata/RHSA-2018:0998", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html", refsource: "CONFIRM", tags: [], url: "http://www.oracle.com/technetwork/security-advisory/cpuapr2018-3678067.html", }, { name: "https://security.netapp.com/advisory/ntap-20180419-0002/", refsource: "CONFIRM", tags: [], url: "https://security.netapp.com/advisory/ntap-20180419-0002/", }, { name: "RHSA-2018:2187", refsource: "REDHAT", tags: [], url: "https://access.redhat.com/errata/RHSA-2018:2187", }, { name: "RHSA-2018:2186", refsource: "REDHAT", tags: [], url: "https://access.redhat.com/errata/RHSA-2018:2186", }, { name: "RHSA-2018:2185", refsource: "REDHAT", tags: [], url: "https://access.redhat.com/errata/RHSA-2018:2185", }, { name: "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html", refsource: "CONFIRM", tags: [], url: "http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html", }, { name: "https://cert-portal.siemens.com/productcert/pdf/ssa-179516.pdf", refsource: "CONFIRM", tags: [], url: "https://cert-portal.siemens.com/productcert/pdf/ssa-179516.pdf", }, { name: "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html", refsource: "MISC", tags: [], url: "https://www.oracle.com/technetwork/security-advisory/cpujul2019-5072835.html", }, ], }, }, impact: { baseMetricV2: { cvssV2: { accessComplexity: "MEDIUM", accessVector: "NETWORK", authentication: "NONE", availabilityImpact: "NONE", baseScore: 4.3, confidentialityImpact: "PARTIAL", integrityImpact: "NONE", vectorString: "AV:N/AC:M/Au:N/C:P/I:N/A:N", version: "2.0", }, exploitabilityScore: 8.6, impactScore: 2.9, obtainAllPrivilege: false, obtainOtherPrivilege: false, obtainUserPrivilege: false, severity: "MEDIUM", userInteractionRequired: false, }, baseMetricV3: { cvssV3: { attackComplexity: "HIGH", attackVector: "NETWORK", availabilityImpact: "NONE", baseScore: 5.9, baseSeverity: "MEDIUM", confidentialityImpact: "HIGH", integrityImpact: "NONE", privilegesRequired: "NONE", scope: "UNCHANGED", userInteraction: "NONE", vectorString: "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N", version: "3.0", }, exploitabilityScore: 2.2, impactScore: 3.6, }, }, lastModifiedDate: "2019-10-03T00:03Z", publishedDate: "2017-12-07T16:29Z", }, }, }
Log in or create an account to share your comment.
Security Advisory comment format.
This schema specifies the format of a comment related to a security advisory.
Title of the comment
Description of the comment
Loading…
Loading…
Loading…
Sightings
Author | Source | Type | Date |
---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.