Fix unconstrained session cache growth in TLSv1.3 (3.2) #24043
Closed
+355
−13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Repeatedly create sessions to be added to the cache and ensure we never exceed the expected size. Related to CVE-2024-2511
Test what happens if the same session gets resumed multiple times at the same time - and one of them gets marked as not_resumable. Related to CVE-2024-2511
In TLSv1.3 we create a new session object for each ticket that we send. We do this by duplicating the original session. If SSL_OP_NO_TICKET is in use then the new session will be added to the session cache. However, if early data is not in use (and therefore anti-replay protection is being used), then multiple threads could be resuming from the same session simultaneously. If this happens and a problem occurs on one of the threads, then the original session object could be marked as not_resumable. When we duplicate the session object this not_resumable status gets copied into the new session object. The new session object is then added to the session cache even though it is not_resumable. Subsequently, another bug means that the session_id_length is set to 0 for sessions that are marked as not_resumable - even though that session is still in the cache. Once this happens the session can never be removed from the cache. When that object gets to be the session cache tail object the cache never shrinks again and grows indefinitely. CVE-2024-2511
Make sure we can't inadvertently use a not_resumable session Related to CVE-2024-2511
Test sessions behave as we expect even in the case that an overflow occurs when adding a new session into the session cache. Related to CVE-2024-2511
mattcaswell
added
approval: review pending
t8m
approved these changes
Apr 5, 2024
t8m
removed
the
approval: otc review pending
nhorman
approved these changes
Apr 5, 2024
t8m
added
approval: done
openssl-machine
added
approval: ready to merge
|
This pull request is ready to merge |
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
Repeatedly create sessions to be added to the cache and ensure we never exceed the expected size. Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
Test what happens if the same session gets resumed multiple times at the same time - and one of them gets marked as not_resumable. Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
In TLSv1.3 we create a new session object for each ticket that we send. We do this by duplicating the original session. If SSL_OP_NO_TICKET is in use then the new session will be added to the session cache. However, if early data is not in use (and therefore anti-replay protection is being used), then multiple threads could be resuming from the same session simultaneously. If this happens and a problem occurs on one of the threads, then the original session object could be marked as not_resumable. When we duplicate the session object this not_resumable status gets copied into the new session object. The new session object is then added to the session cache even though it is not_resumable. Subsequently, another bug means that the session_id_length is set to 0 for sessions that are marked as not_resumable - even though that session is still in the cache. Once this happens the session can never be removed from the cache. When that object gets to be the session cache tail object the cache never shrinks again and grows indefinitely. CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
Make sure we can't inadvertently use a not_resumable session Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
openssl-machine
pushed a commit
that referenced
this pull request
Apr 8, 2024
Test sessions behave as we expect even in the case that an overflow occurs when adding a new session into the session cache. Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #24043)
|
Merged to the 3.2 branch. Thank you. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In TLSv1.3 we create a new session object for each ticket that we send.
We do this by duplicating the original session. If SSL_OP_NO_TICKET is in
use then the new session will be added to the session cache. However, if
early data is not in use (and therefore anti-replay protection is being
used), then multiple threads could be resuming from the same session
simultaneously. If this happens and a problem occurs on one of the threads,
then the original session object could be marked as not_resumable. When we
duplicate the session object this not_resumable status gets copied into the
new session object. The new session object is then added to the session
cache even though it is not_resumable.
Subsequently, another bug means that the session_id_length is set to 0 for
sessions that are marked as not_resumable - even though that session is
still in the cache. Once this happens the session can never be removed from
the cache. When that object gets to be the session cache tail object the
cache never shrinks again and grows indefinitely.
CVE-2024-2511