It's a tricky bug I spend some time on it. I haven't figured out yet what is the correct logic. I think curl should be able to know if the certificate structure has already be cleaned by a closing of the ssl connexion.

The usual way to avoid such problem is to set the pointer to NULL after it is freed. But in this case, I think the certificate parsed structure is part of another big structure which is free (as the client certificate is part of the ssl connection), and the cleaning is made into the libssl library.

---
** [bugs:#1236] Curl double-free with pkcs12 handling**
**Status:** open
**Created:** Fri May 31, 2013 10:06 PM UTC by Nikaiw
**Last Updated:** Mon Jun 10, 2013 02:01 PM UTC
**Owner:** Daniel Stenberg
Summary :
-------
There is a double free bug in curl when using p12 client certificate to connect to an https server.
Steps to reproduce :
------------------
Connect to any https server using a client certificate in pkcs12 format.
curl -vvv --cert yourcertificate.p12:yourpassword --cert-type P12 https://yourserver.com
eg:
* About to connect() to ************ port 443 (#0)
*   Trying **********...
* Connected to ********** (*.*.*.*) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Erreur de segmentation (core dumped)
Bug is 100% reproducible.
Affected version :
----------------
Affected version are curl-7.24 to 7.30. 
Details :
--------
Bug was introduced in following commit to fix a memory leak: 
https://github.com/bagder/curl/commit/6ea7acf5a96786f7514be4fbce174cdc8bedfdd1
on line 512 of ssluse.c:  sk_X509_pop_free(ca, X509_free);
curl is freeing data related to the handling of the certificate which may have already being freed by SSL_CTX_free call made on line 865 of ssluse.c when we are closing the ssl connexion.
Here is a valgrind stacktrace:
==4136== Invalid free() / delete / delete[] / realloc()
==4136==    at 0x4C2BA6C: free (vg_replace_malloc.c:446)
==4136==    by 0x5B964EC: CRYPTO_free (mem.c:397)
==4136==    by 0x5C4029F: asn1_item_combine_free (tasn_fre.c:176)
==4136==    by 0x5C40484: ASN1_item_free (tasn_fre.c:71)
==4136==    by 0x5C1E96F: sk_pop_free (stack.c:283)
==4136==    by 0x590F806: SSL_CTX_free (ssl_lib.c:1947)
==4136==    by 0x4E67BD4: Curl_ossl_close (ssluse.c:865)
==4136==    by 0x4E89822: Curl_ssl_close (sslgen.c:421)
==4136==    by 0x4E60906: Curl_disconnect (url.c:2565)
==4136==    by 0x4E81B40: multi_runsingle (multi.c:1637)
==4136==    by 0x4E81D54: curl_multi_perform (multi.c:1708)
==4136==    by 0x4E76CDC: curl_easy_perform (easy.c:448)
==4136==  Address 0x6636d00 is 0 bytes inside a block of size 184 free'd
==4136==    at 0x4C2BA6C: free (vg_replace_malloc.c:446)
==4136==    by 0x5B964EC: CRYPTO_free (mem.c:397)
==4136==    by 0x5C4029F: asn1_item_combine_free (tasn_fre.c:176)
==4136==    by 0x5C40484: ASN1_item_free (tasn_fre.c:71)
==4136==    by 0x5C1E96F: sk_pop_free (stack.c:283)
==4136==    by 0x4E67378: cert_stuff (ssluse.c:510)
==4136==    by 0x4E68F54: ossl_connect_step1 (ssluse.c:1524)
==4136==    by 0x4E6BBC8: ossl_connect_common (ssluse.c:2433)
==4136==    by 0x4E6BE46: Curl_ossl_connect_nonblocking (ssluse.c:2522)
==4136==    by 0x4E890A2: Curl_ssl_connect_nonblocking (sslgen.c:218)
==4136==    by 0x4E49D5C: https_connecting (http.c:1345)
==4136==    by 0x4E49CBA: Curl_http_connect (http.c:1315)
I'm not sure the bug is exploitable nor i see any practical case.
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1236/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>