Description Instances of ssl.SSLSocket are vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data if the socket is closed before initiating its own handshake.

This vulnerability is of severity: *HIGH*.

The vulnerability is caused when a socket is connected, data is sent by the malicious peer and stored in a buffer, and then the malicious peer closes the socket within a small timing window before the other peers’ TLS handshake can begin. After this sequence of events the closed socket will not immediately attempt a TLS handshake due to not being connected but will also allow the buffered data to be read as if a successful TLS handshake had occurred.

Affected usages

This vulnerability *primarily affects* HTTPS servers and other server-side protocols using TLS client authentication (such as mTLS) due to requiring reading data immediately after the handshake to be vulnerable. Operations which would fail on a closed socket (like sending data) immediately after the handshake are not affected by this vulnerability.

Because disconnecting the socket is a necessary step to trigger the vulnerability *there is no risk of data exfiltration or data leakage directly from the malicious TLS connection*, however the vulnerability *does* carry risk for modifying or deleting resources which are authenticated using only TLS client certificates.

This vulnerability *affects* clients who are reading and processing data from the server after a TLS handshake without sending any data first. Our team is unaware of a protocol that uses TLS that fits this usage pattern.

This vulnerability *does not affect* client-side HTTPS connections like pip or requests as an HTTP request must be sent before an HTTP response is read meaning the connection would already be closed by the time the client is sending an HTTP request, leading to an error.

This vulnerability *affects, but has no impact* on servers that aren’t using TLS client certificate authentication as traffic to a non-authenticating TLS server loses nothing from a bypassed handshake to inject a query and close the connection as the same action could be taken by a peer using a TLS connection with a proper handshake.

Affected versions

• Python 3.12.0a1 to 3.12.0rc1 *
• Python 3.11.0 to 3.11.4
• Python 3.10.0 to 3.10.12
• Python 3.9.0 to 3.9.17
• Python 3.8.0 to 3.8.17
• Python 3.7.17 and earlier **

• Note that Python 3.12.0rc2 will not be published for a few weeks. *Pre-release versions of Python are not recommended for production use.*

** *Note that Python 3.7.17 and earlier will not be receiving an upstream security fix due to being end-of-life <https://devguide.python.org/versions/#versions>,* contact your distributor of Python for additional guidance.

Remediation and work-arounds

• Upgrade to Python 3.11.5, 3.10.13, 3.9.18, or 3.8.18.
• Apply a patch for your corresponding version of Python.
• Add a call to SSLSocket.getpeername() after calling SSLSocket.wrap_socket() before any calls to SSLSocket.recv(). This call to getpeername() will raise an OSError if the socket isn’t connected thus mitigating the vulnerability.

Patches are available for all affected feature, bugfix, and security branches of Python:

main: 0cb0c238d520a8718e313b52cffc356a5a7561bf <https://github.com/python/cpython/commit/0cb0c238d520a8718e313b52cffc356a5a7...>

3.12: 256586ab8776e4526ca594b4866b9a3492e628f1 <https://github.com/python/cpython/commit/256586ab8776e4526ca594b4866b9a3492e...>

3.11: 75a875e0df0530b75b1470d797942f90f4a718d3 <https://github.com/python/cpython/commit/75a875e0df0530b75b1470d797942f90f4a...>

3.10: 37d7180cb647f0bed0c1caab0037f3bc82e2af96 <https://github.com/python/cpython/commit/37d7180cb647f0bed0c1caab0037f3bc82e...>

3.9: 264b1dacc67346efa0933d1e63f622676e0ed96b <https://github.com/python/cpython/commit/264b1dacc67346efa0933d1e63f622676e0...>

3.8: b4bcc06a9cfe13d96d5270809d963f8ba278f89b <https://github.com/python/cpython/commit/b4bcc06a9cfe13d96d5270809d963f8ba27...>

Additional patches to stabilize the test suite may also be applied to all versions:

• 64f99350351bc46e016b2286f36ba7cd669b79e3 <https://github.com/python/cpython/commit/64f99350351bc46e016b2286f36ba7cd669...>
• 592bacb6fc0833336c0453e818e9b95016e9fd47 <https://github.com/python/cpython/commit/592bacb6fc0833336c0453e818e9b95016e...>

References

https://github.com/python/cpython/issues/108310

https://github.com/python/cpython/pull/108315

Credits

• Reporter: Aapo Oksman
• Remediation Developer: Gregory P. Smith
• Remediation Reviewer: Thomas Wouters
• Coordinator: Seth Michael Larson

Timeline

• August 8,2023: Reported by Aapo Oksman to security@python.org.
• August 8, 2023: Acknowledged the report.
• August 9, 2023: Acknowledgement of the vulnerability, sent CVE ID request to MITRE.
• August 10, 2023: CVE-2023-40217 assigned by MITRE.
• August 15, 2023: Patch authored by Gregory P Smith, reviewed by Thomas Wouters.
• August 22, 2023: Patch applied to feature and security branches by Łukasz Langa.
• August 24, 2023: Python 3.11.5, 3.10.13, 3.9.18, 3.8.18 are published containing the fix for CVE-2023-40217.
• August 24, 2023: Advisory published.