[openssl-users] Openssl static build linked in DLL does not unload on win32

[Dan Heinz]

>>>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c.
>>>> 
>>>> I have a test application that is a win32 console app that calls a >
>>> win32 DLL which has the openssl libraries linked in statically>.
>>>> 
>>>> The test applications uses late-binding to the DLL and calls 
>>>> LoadLibrary for the DLL, one test function in the DLL, and then 
>>>> FreeLibrary on the DLL.>
>>>> 
>>>> 
>>>> 
>>>> The test function in the DLL does the following:>
>>>> 
>>>> RSA*rsa = NULL;
>>>> 
>>>> rsa = RSA_new();>
>>>> 
>>>> RSA_free(rsa);
>>>> 
>>>> OPENSSL_thread_stop();>
>>>> 
>>>> OPENSSL_cleanup();
>>>> 
>>>> return0;>
>>>> 
>>>> When FreeLibrary is called on the DLL, dllmain in never called with 
>>>> any messages.  A subsequent call to LoadLibrary also fails to call 
>>>> dllmain and when the test function is called RSA_new() fails.  This >
>>> leads me to believe the DLL is never freed>.
>>>> 
>>>> I have tried building openssl with and without no-threads with the 
>>>> same results.  My build parameters are: perl Configure
>>>> *%TEMP_ARCHITECTURE%*>
>>> --prefix=*%RootPath_T>hirdParty%*\*%OPENSSL_VERSION%* -DPURIFY 
>>> -DOPENSSL_NO_COMP -D>_USING_V110_SDK71_ no-shared no-threads no-asm 
>>> no-idea no-mdc2 no->rc5  no-ssl3 no-zlib no-comp
>>>> 
>>>> What am I missing?
>>> 
>>> >
>> >OpenSSL does its cleanup at *process* exit. Don't call
>>> OPENSSL_cleanup() explicitly - this is >discouraged.
>>> 
>>> From this manpage:>
>>> 
>>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
>>>>
>>>>
>>>>
"Ty>pically there should be no need to call this function directly as it is initiated >a>utomatically on application exit...<snip>...
>>> 
>>> Once OPENSSL_cleanup() has been called the library cannot be >
>>> reinitialised.>"
>>> 
>>> This last sentence is the reason why RSA_new() will fail after you 
>>> have previously called >OPENSSL_cleanup().>
>>> 
>>> Because cleanup happens on process exit, OpenSSL will keep itself in 
>>> memory until that time >(otherwise crashes will occur because the >
>>> cleanup routines have been unloaded)>.
>>> 
>>> If you want to dynamically load and unload your DLL then don't 
>>> statically link it to OpenSSL - >otherwise OpenSSL will keep your DLL >
>>> around until process exit too>.
>>> 
>>> Matt
>>>
>>That is very disappointing.  As a library vendor we have no control 
>> over how our users load and unload our libraries.  We will just have 
>> to roll back to 1.0.x and wait to see if this will be addressed.
>> Also, as Jakob stated in another post, it really seems like this
>> design will be problematic.
>
>Can you not link against the OpenSSL DLLs rather than statically link?
>That would avoid the problem.

Unfortunately, no.  We need to control the version of OpenSSL, and our users generally do not wish to have to distribute another DLL.  In addition, the static link adds a bit more protection from tampering.  I see you posted a link elsewhere to the discussion regarding this decision and I will examine it.  Being able to explicitly initialize and exit the library would certainly fix the issue for us and most likely others who will run into this same issue.

Thanks,
Dan