ubuntu-cve-2017-3737
Vulnerability from osv_ubuntu
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.
{
"affected": [
{
"ecosystem_specific": {
"availability": "No subscription required",
"binaries": [
{
"binary_name": "libssl1.0.0",
"binary_version": "1.0.2g-1ubuntu4.10"
},
{
"binary_name": "openssl",
"binary_version": "1.0.2g-1ubuntu4.10"
}
]
},
"package": {
"ecosystem": "Ubuntu:16.04:LTS",
"name": "openssl",
"purl": "pkg:deb/ubuntu/openssl@1.0.2g-1ubuntu4.10?arch=source\u0026distro=xenial"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2g-1ubuntu4.10"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1.0.2d-0ubuntu1",
"1.0.2d-0ubuntu2",
"1.0.2e-1ubuntu1",
"1.0.2f-2ubuntu1",
"1.0.2g-1ubuntu2",
"1.0.2g-1ubuntu3",
"1.0.2g-1ubuntu4",
"1.0.2g-1ubuntu4.1",
"1.0.2g-1ubuntu4.2",
"1.0.2g-1ubuntu4.4",
"1.0.2g-1ubuntu4.5",
"1.0.2g-1ubuntu4.6",
"1.0.2g-1ubuntu4.8",
"1.0.2g-1ubuntu4.9"
]
}
],
"aliases": [],
"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": "UBUNTU-CVE-2017-3737",
"modified": "2026-04-22T07:38:09Z",
"published": "2017-12-07T00:00:00Z",
"references": [
{
"type": "REPORT",
"url": "https://ubuntu.com/security/CVE-2017-3737"
},
{
"type": "REPORT",
"url": "https://www.openssl.org/news/secadv/20171207.txt"
},
{
"type": "ADVISORY",
"url": "https://ubuntu.com/security/notices/USN-3512-1"
},
{
"type": "REPORT",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3737"
}
],
"related": [
"USN-3512-1"
],
"schema_version": "1.7.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "medium",
"type": "Ubuntu"
}
],
"upstream": [
"CVE-2017-3737"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.