[openssl-users] openssl-users Digest, Vol 28, Issue 33

ghanashyam satpathy ghanashyam.satpathy at gmail.com
Sat Mar 25 16:37:15 UTC 2017


It seems any TLS being allocated from the call stack of ERR_get_state() is
not getting freed. I used an OPENSSL sample  demos\bio\server-cmod.c and it
reproduces the issue.
Any tips to resolve this issue is appreciated.

> testConsoleApplication.exe!CRYPTO_THREAD_init_local(unsigned long * key,
void (void *) * cleanup) Line 93 C
  testConsoleApplication.exe!err_do_init() Line 637 C
  testConsoleApplication.exe!err_do_init_ossl_() Line 634 C
  testConsoleApplication.exe!CRYPTO_THREAD_run_once(long * once, void
(void) * init) Line 82 C
  testConsoleApplication.exe!ERR_get_state() Line 643 C
  testConsoleApplication.exe!ERR_put_error(int lib, int func, int reason,
const char * file, int line) Line 358 C
  testConsoleApplication.exe!BIO_new_file(const char * filename, const char
* mode) Line 75 C
  testConsoleApplication.exe!def_load(conf_st * conf, const char * name,
long * line) Line 140 C
  testConsoleApplication.exe!NCONF_load(conf_st * conf, const char * file,
long * eline) Line 217 C
  testConsoleApplication.exe!CONF_modules_load_file(const char * filename,
const char * appname, unsigned long flags) Line 129 C
  testConsoleApplication.exe!main(int argc, char * * argv) Line 120 C++
  [External Code]

//demos\bio\server-cmod.c

#include <stdio.h> #include <signal.h> #include <openssl/err.h> #include
<openssl/ssl.h> #include <openssl/conf.h> int main(int argc, char *argv[])
{ unsigned char buf[512]; char *port = "*:4433"; BIO *in = NULL; BIO
*ssl_bio, *tmp; SSL_CTX *ctx; int ret = 1, i; ctx =
SSL_CTX_new(TLS_server_method()); if (CONF_modules_load_file("cmod.cnf",
"testapp", 0) <= 0) { fprintf(stderr, "Error processing config file\n");
goto err; } if (SSL_CTX_config(ctx, "server") == 0) { fprintf(stderr,
"Error configuring server.\n"); goto err; } /* Setup server side SSL bio */
ssl_bio = BIO_new_ssl(ctx, 0); if ((in = BIO_new_accept(port)) == NULL)
goto err; /* * This means that when a new connection is accepted on 'in',
The ssl_bio * will be 'duplicated' and have the new socket BIO push into
it. * Basically it means the SSL BIO will be automatically setup */
BIO_set_accept_bios(in, ssl_bio); again: /* * The first call will setup the
accept socket, and the second will get a * socket. In this loop, the first
actual accept will occur in the * BIO_read() function. */ if
(BIO_do_accept(in) <= 0) goto err; for (;;) { i = BIO_read(in, buf,
sizeof(buf)); if (i == 0) { /* * If we have finished, remove the underlying
BIO stack so the * next time we call any function for this BIO, it will
attempt * to do an accept */ printf("Done\n"); tmp = BIO_pop(in);
BIO_free_all(tmp); goto again; } if (i < 0) { if (BIO_should_retry(in))
continue; goto err; } fwrite(buf, 1, i, stdout); fflush(stdout); } ret = 0;
err: if (ret) { ERR_print_errors_fp(stderr); } BIO_free(in); exit(ret);
return (!ret); }



On Sat, Mar 25, 2017 at 8:59 PM, ghanashyam satpathy <
ghanashyam.satpathy at gmail.com> wrote:

> However this type of TLS leak was not there when my application was using
> OpenSSL 1.0.2
> Noticed after using OpenSSL 1.1.0b
>
> On Sat, Mar 25, 2017 at 8:12 PM, <openssl-users-request at openssl.org>
> wrote:
>
>> Send openssl-users mailing list submissions to
>>         openssl-users at openssl.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mta.openssl.org/mailman/listinfo/openssl-users
>> or, via email, send a message with subject or body 'help' to
>>         openssl-users-request at openssl.org
>>
>> You can reach the person managing the list at
>>         openssl-users-owner at openssl.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openssl-users digest..."
>>
>>
>> Today's Topics:
>>
>>    1. OpenSSL sending close_notify right after responding       to a
>>       heartbeat request (R Kaja Mohideen)
>>    2. Re: how to implement functions for STACK OF custom type?
>>       (Dr. Stephen Henson)
>>    3. TLSv1_2_method (Lei Kong)
>>    4. Re: TLSv1_2_method (Viktor Dukhovni)
>>    5. TLS leak for openssl 1.1.0b with libcurl 7.50.3
>>       (ghanashyam satpathy)
>>    6. Re: TLS leak for openssl 1.1.0b with libcurl 7.50.3 (Salz, Rich)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 24 Mar 2017 19:10:41 +0530
>> From: R Kaja Mohideen <reachme at kajasweb.com>
>> To: openssl-users at openssl.org
>> Subject: [openssl-users] OpenSSL sending close_notify right after
>>         responding      to a heartbeat request
>> Message-ID:
>>         <CAMSoAtDCh7AZTBJeOtVa=Gdk3YZ2yTStdwem56eN_d=eNVgaCQ at mail.
>> gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi,
>>
>> We have a TLS Server (Written in C) and Client (Written in Java using
>> Netty + OpenSSL).
>>
>> I see that when Server sends a TLS extension Heartbeat request to
>> client - OpenSSL responds to it and sends a close_notify alert right
>> after it - causing the server to close the session with client.
>>
>> I don't have any callback registered in client (HB request recipient
>> side - Java/Netty doesn't really have that support) and so I'm sure
>> that it is OpenSSL by itself is responding to that heartbeat request.
>> But, who or what is making OpenSSL to send an alert & close the
>> session upon responding to heartbeat remains a mystery.
>>
>> Any help / suggestions to investigate this issue is highly appreciated.
>>
>> Thanks & regards,
>> R Kaja Mohideen
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 24 Mar 2017 17:46:28 +0000
>> From: "Dr. Stephen Henson" <steve at openssl.org>
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] how to implement functions for STACK OF
>>         custom type?
>> Message-ID: <20170324174628.GA16753 at openssl.org>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> On Tue, Mar 21, 2017, lists wrote:
>>
>> > Sorry, I first posted this on the -dev list, likely inappropriate...
>> now with an update:
>> >
>> > I am exploring my options with OpenSSL and specifically I am trying to
>> manage the stacks for some custom objects.
>> > Currently, I have this code (sort of) in the headers:
>> >
>> > typedef struct myThingA_st
>> > {
>> > ???? ASN1_OBJECT aID;
>> > ???? ASN1_OCTET_STRING aOCST;
>> > }
>> > ???? myThingA;
>> >
>> > DECLARE_ASN1_ITEM(myThingA)
>> > DECLARE_ASN1_FUNCTIONS(myThingA)
>> > DECLARE_STACK_OF(myThingA)
>> > // the next one seems to be ininfluent for my purpose, is it?
>> > DECLARE_ASN1_SET_OF(myThingA)
>> >
>> > typedef struct myThingB_st
>> > {
>> > ???? // SEQUENCE OF { ... }
>> > ???? STACK_OF(myThingA) myThingA_sk;
>> > }
>> > ???? myThingB;
>> >
>> > // DECLARE_ASN1_ITEM(myThingB)
>> > DECLARE_STACK_OF(myThingB)
>> > // DECLARE_ASN1_FUNCTIONS(myThingB)
>> > // the next one seems to be ininfluent for my purpose, is it?
>> > DECLARE_ASN1_SET_OF(myThingB)
>> >
>> > Then, in the .c file...
>> >
>> > IMPLEMENT_STACK_OF(myThingA)
>> > IMPLEMENT_STACK_OF(myThingB)
>> >
>> > I thought that the basic functions for the stacks to be available (such
>> as sk_myThingA_new, sk_myThingA_push...), yet by compiling a main, for
>> > the first one that I try to use I get:
>> >
>> > ?????? undefined reference to `sk_myThingA_value'
>> >
>> > What am I doing wrong here?
>>
>> If you're using OpenSSL 1.1.0 you need to include:
>>
>> DEFINE_STACK_OF(FOO)
>>
>> in a header file and that should be it. That implements a set of inline
>> functions that do the right thing.
>>
>> For OpenSSL versions before 1.1.0 it's a bit messier. The type specific
>> STACK_OF functions are actually macros which are generated by the
>> mkstack.pl
>> script and appear in the safestack.h header file. If you want to create
>> your
>> own one way is to extract a type specific section from safestack.h, copy
>> it
>> to your own header file and do a search/replace for the new type.
>>
>> So for example extract the sk_OPENSSL_BLOCK macros and replace
>> OPENSSL_BLOCK
>> with FOO.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 24 Mar 2017 21:51:07 +0000
>> From: Lei Kong <leikong at msn.com>
>> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
>> Subject: [openssl-users] TLSv1_2_method
>> Message-ID:
>>         <BN1PR01MB021823477985DD1AFB7D042A83E0 at BN1PR01MB021.prod.exc
>> hangelabs.com>
>>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Can processes running with TLSv1_2_method talk to processes running with
>> something older, e.g. TLSv1_1_method? Along the same lines, will new TLS
>> versions be backward compatible with TLSv1_2_method ?
>>
>> I would like to make my code proof, is there something like
>> TLS_latest_method()?
>>
>> I have a cluster of nodes that talk to each other with TLS, currently the
>> version is hardcoded to TLSv1_2_method. Suppose TLSv1_2 is deprecated by
>> TLS_new one day, I update my service to use TLS_new node by node, during
>> this time, some old nodes are running with TLSv1_2, some new nodes are
>> running with new TLS_new, will the communication between old and new nodes
>> work?
>>
>> Thanks.
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/
>> 20170324/1f4d53f0/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sat, 25 Mar 2017 03:19:55 -0400
>> From: Viktor Dukhovni <openssl-users at dukhovni.org>
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] TLSv1_2_method
>> Message-ID: <5D881D46-87A5-4053-B166-F1EE4AA52619 at dukhovni.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>>
>> > On Mar 24, 2017, at 5:51 PM, Lei Kong <leikong at msn.com> wrote:
>> >
>> > TLS_latest_method
>>
>> https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_new.html
>>
>>    ...
>>
>>    TLS_method(), TLS_server_method(), TLS_client_method()
>>
>>    These are the general-purpose version-flexible SSL/TLS methods.
>>    The actual protocol version used will be negotiated to the
>>    highest version mutually supported by the client and the server.
>>    The supported protocols are SSLv3, TLSv1, TLSv1.1 and TLSv1.2.
>>    Applications should use these methods, and avoid the version-specific
>>    methods described below.
>>
>> With OpenSSL 1.0.2 these are called SSLv23_method(), ...
>>
>>    https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_new.html
>>
>> --
>>         Viktor.
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sat, 25 Mar 2017 19:35:06 +0530
>> From: ghanashyam satpathy <ghanashyam.satpathy at gmail.com>
>> To: openssl-users at openssl.org
>> Subject: [openssl-users] TLS leak for openssl 1.1.0b with libcurl
>>         7.50.3
>> Message-ID:
>>         <CAKn+8OKWHspSvk=sxZfz3PSOZK5qXkWQTy3z+3PimCiFrOnXkw at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I use libcurl 7.50.3 as statically linked in my application dll , along
>> with openssl 1.1.0b also statically linked. The dll is dynamically loaded
>> using LoadLibrary() and unloaded using FreeLibrary() inside application
>> exe. I observed a TLS index is not getting freed which was allocated
>> inside
>> openssl. To narrow down the issue I have following exported function,
>> which
>> I call from my application exe. After FreeLibrary() I see the TLS leak
>> through APplication verifier.
>>
>> extern "C" __declspec(dllexport)
>> void CurlSetup()
>> {
>>
>> curl_global_init(CURL_GLOBAL_DEFAULT);
>>  curl_global_cleanup();
>> return;
>>
>> }
>>
>> An early reply in this context is appreciated.
>>
>> Thanks
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/
>> 20170325/12c0ccde/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Sat, 25 Mar 2017 14:13:47 +0000
>> From: "Salz, Rich" <rsalz at akamai.com>
>> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
>> Subject: Re: [openssl-users] TLS leak for openssl 1.1.0b with libcurl
>>         7.50.3
>> Message-ID:
>>         <6d87957f6c654825a6a6c6f0d3d4a20a at usma1ex-dag1mb1.msg.corp.a
>> kamai.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Those are curl functions, not openssl
>>
>> --
>> Senior Architect, Akamai Technologies
>> Member, OpenSSL Dev Team
>> IM: richsalz at jabber.at Twitter: RichSalz
>>
>> From: ghanashyam satpathy [mailto:ghanashyam.satpathy at gmail.com]
>> Sent: Saturday, March 25, 2017 10:05 AM
>> To: openssl-users at openssl.org
>> Subject: [openssl-users] TLS leak for openssl 1.1.0b with libcurl 7.50.3
>>
>> I use libcurl 7.50.3 as statically linked in my application dll , along
>> with openssl 1.1.0b also statically linked. The dll is dynamically loaded
>> using LoadLibrary() and unloaded using FreeLibrary() inside application
>> exe. I observed a TLS index is not getting freed which was allocated
>> inside
>> openssl. To narrow down the issue I have following exported function,
>> which
>> I call from my application exe. After FreeLibrary() I see the TLS leak
>> through APplication verifier.
>>
>> extern "C" __declspec(dllexport)
>> void CurlSetup()
>> {
>>
>> curl_global_init(CURL_GLOBAL_DEFAULT);
>>  curl_global_cleanup();
>> return;
>>
>> }
>>
>> An early reply in this context is appreciated.
>>
>> Thanks
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/
>> 20170325/1a5b8980/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>> ------------------------------
>>
>> End of openssl-users Digest, Vol 28, Issue 33
>> *********************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170325/3bebe198/attachment-0001.html>


More information about the openssl-users mailing list