Fix unconstrained session cache growth in TLSv1.3 (3.1/3.0) #24044

mattcaswell · 2024-04-05T08:51:13Z

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

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

Related to 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 · 2024-04-05T11:33:46Z

The last fixup commit is a workaround for the bug described in #24046 which this test stumbled into.

test/sslapitest.c

openssl-machine · 2024-04-06T14:00:08Z

This pull request is ready to merge

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 #24044)

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 #24044)

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 openssl#24044) (cherry picked from commit 5f5b9e1)

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 openssl/openssl#24044) (cherry picked from commit 5f5b9e1ca1fad0215f623b8bd4955a2e8101f306) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 031b11a4054c972a5e2f07dfa81ce1842453253e) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 7e4d731b1c07201ad9374c1cd9ac5263bdf35bce) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit c342f4b8bd2d0b375b0e22337057c2eab47d9b96) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit ddead0935d77ba9b771d632ace61b145d7153f18) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 5f5b9e1ca1fad0215f623b8bd4955a2e8101f306) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 031b11a4054c972a5e2f07dfa81ce1842453253e) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 7e4d731b1c07201ad9374c1cd9ac5263bdf35bce) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit c342f4b8bd2d0b375b0e22337057c2eab47d9b96) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit ddead0935d77ba9b771d632ace61b145d7153f18) Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 7e4d731b1c07201ad9374c1cd9ac5263bdf35bce) Signed-off-by: Liu-Ermeng <liuermeng2@huawei.com> Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 5f5b9e1ca1fad0215f623b8bd4955a2e8101f306) Signed-off-by: Liu-Ermeng <liuermeng2@huawei.com> Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit 031b11a4054c972a5e2f07dfa81ce1842453253e) Signed-off-by: Liu-Ermeng <liuermeng2@huawei.com> Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit c342f4b8bd2d0b375b0e22337057c2eab47d9b96) Signed-off-by: Liu-Ermeng <liuermeng2@huawei.com> Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl/openssl#24044) (cherry picked from commit ddead0935d77ba9b771d632ace61b145d7153f18) Signed-off-by: Liu-Ermeng <liuermeng2@huawei.com> Signed-off-by: hhhFun <fanghaojie@huawei.com>

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 openssl#24044) (cherry picked from commit 7e4d731)

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 openssl#24044) (cherry picked from commit 5f5b9e1)

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 openssl#24044) (cherry picked from commit 031b11a)

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 openssl#24044) (cherry picked from commit ddead09)

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 openssl#24044) (cherry picked from commit c342f4b)

Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#24044) (cherry picked from commit e32ad41)

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 openssl#24044) (cherry picked from commit 7e4d731)

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 openssl#24044) (cherry picked from commit 5f5b9e1)

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 openssl#24044) (cherry picked from commit 031b11a)

Related to CVE-2024-2511 Reviewed-by: Neil Horman <nhorman@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from openssl#24044) (cherry picked from commit e32ad41)

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 openssl#24044) (cherry picked from commit c342f4b)

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 openssl#24044) (cherry picked from commit ddead09)

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 openssl/openssl#24044) (cherry picked from commit ddead0935d77ba9b771d632ace61b145d7153f18)

mattcaswell added 6 commits April 5, 2024 08:58

Add a test for session cache handling

f74d322

Repeatedly create sessions to be added to the cache and ensure we never exceed the expected size. Related to CVE-2024-2511

Extend the multi_resume test for simultaneous resumptions

546e223

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

Add a CHANGES.md/NEWS.md entry for the unbounded memory growth bug

bf4a323

Related to CVE-2024-2511

Hardening around not_resumable sessions

c3e0159

Make sure we can't inadvertently use a not_resumable session Related to CVE-2024-2511

Add a test for session cache overflow

f0f54b0

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 mentioned this pull request Apr 5, 2024

Don't use a non-resumable session if it is returned from the cache #18810

Closed

mattcaswell added 5 commits April 5, 2024 10:29

fixup! Add a test for session cache overflow

d37a821

fixup! Extend the multi_resume test for simultaneous resumptions

d1674b9

fixup! Add a test for session cache overflow

b72b89f

fixup! Add a test for session cache overflow

4e8e9c4

fixup! Add a test for session cache overflow

a0fcd04

t8m approved these changes Apr 5, 2024

View reviewed changes

t8m removed the approval: otc review pending This pull request needs review by an OTC member label Apr 5, 2024

nhorman approved these changes Apr 5, 2024

View reviewed changes

tom-cosgrove-arm reviewed Apr 5, 2024

View reviewed changes

test/sslapitest.c Show resolved Hide resolved

t8m added approval: done This pull request has the required number of approvals and removed approval: review pending This pull request needs review by a committer labels Apr 5, 2024

openssl-machine added approval: ready to merge The 24 hour grace period has passed, ready to merge and removed approval: done This pull request has the required number of approvals labels Apr 6, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix unconstrained session cache growth in TLSv1.3 (3.1/3.0) #24044

Fix unconstrained session cache growth in TLSv1.3 (3.1/3.0) #24044

mattcaswell commented Apr 5, 2024

mattcaswell commented Apr 5, 2024

openssl-machine commented Apr 6, 2024

Fix unconstrained session cache growth in TLSv1.3 (3.1/3.0) #24044

Fix unconstrained session cache growth in TLSv1.3 (3.1/3.0) #24044

Conversation

mattcaswell commented Apr 5, 2024

mattcaswell commented Apr 5, 2024

openssl-machine commented Apr 6, 2024