Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nss: only cache valid CRL entries #4053

Closed

Conversation

@danielgustafsson
Copy link
Member

danielgustafsson commented Jun 20, 2019

Change the logic around such that we only keep CRLs that NSS actually ended up caching around for later deletion. If CERT_CacheCRL() fails then there is little point in delaying the freeing of the CRL as it is not used.

/* unable to cache CRL */
/* store the CRL item so that we can free it in Curl_nss_cleanup() */
if(insert_wrapped_ptr(&nss_crl_list, crl_der) != CURLE_OK) {
SECITEM_FreeItem(crl_der, PR_TRUE);

This comment has been minimized.

Copy link
@kdudka

kdudka Jun 20, 2019

Collaborator

You need to call CERT_UncacheCRL() before releasing the memory to avoid a possible use after free later on. If CERT_UncacheCRL() fails, which is unlikely, it is IMO better to leak the memory. Something like:

if(SECSuccess == CERT_UncacheCRL(db, crl_der))
  SECITEM_FreeItem(crl_der, PR_TRUE);

This comment has been minimized.

Copy link
@danielgustafsson

danielgustafsson Jun 20, 2019

Author Member

Ah, nice catch, fixed and rebased.

Change the logic around such that we only keep CRLs that NSS actually
ended up caching around for later deletion.  If CERT_CacheCRL() fails
then there is little point in delaying the freeing of the CRL as it
is not used.

Closes #xxxx
@danielgustafsson danielgustafsson force-pushed the danielgustafsson:dg-nss_crl_cache branch from 19f1cda to f33f352 Jun 20, 2019
@danielgustafsson

This comment has been minimized.

Copy link
Member Author

danielgustafsson commented Jun 20, 2019

A thing to note which I failed to write in the commitmessage (but will amend before pushing if approved) is that without this we leave a dangling pointer on nss_crl_list as we perform SECITEM_FreeItem() on the underlying storage pointed to in case CRL caching fails.

@kdudka

This comment has been minimized.

Copy link
Collaborator

kdudka commented Jun 20, 2019

A thing to note which I failed to write in the commitmessage (but will amend before pushing if approved) is that without this we leave a dangling pointer on nss_crl_list as we perform SECITEM_FreeItem() on the underlying storage pointed to in case CRL caching fails.

I do not understand the above note. Are you talking about the original implementation? It did not (immediately) call SECITEM_FreeItem() upon failure of CERT_CacheCRL(). The only problem was that the memory was released too late as I understand it.

@danielgustafsson

This comment has been minimized.

Copy link
Member Author

danielgustafsson commented Jun 20, 2019

@kdudka

This comment has been minimized.

Copy link
Collaborator

kdudka commented Jun 20, 2019

No problem, thank you for clarifying it! And thank you for improving the code!

@kdudka
kdudka approved these changes Jun 20, 2019
@jay jay closed this in 2028a1a Jul 7, 2019
@jay

This comment has been minimized.

Copy link
Member

jay commented Jul 7, 2019

Thanks

caraitto added a commit to caraitto/curl that referenced this pull request Jul 23, 2019
Change the logic around such that we only keep CRLs that NSS actually
ended up caching around for later deletion.  If CERT_CacheCRL() fails
then there is little point in delaying the freeing of the CRL as it
is not used.

Closes curl#4053
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
3 participants
You can’t perform that action at this time.