Potential memory leak in RSA_private_decrypt

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential memory leak in RSA_private_decrypt

Wang
This post was updated on .
Hello,

The memory usage of one of our OpenSSL applications increases quickly.
Valgrind detects the only possible leak below. We are using OpenSSL 1.0.2k.

==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of
1,294
==9721==    at 0x4A0817C: malloc (vg_replace_malloc.c:298)
==9721==    by 0x5B29CD0: comn_malloc (comalloc.c:28)
==9721==    by 0x58E7DD2: comn__csi_malloc (netenc2.c:52)
==9721==    by 0xBBC37EA: local_malloc (csi_provider_common.c:624)
==9721==    by 0xBC1747F: default_malloc_ex (mem.c:79)
==9721==    by 0xBC17BA6: CRYPTO_malloc (mem.c:350)
==9721==    by 0xBC2648F: bn_expand_internal (bn_lib.c:303)
==9721==    by 0xBC266AA: bn_expand2 (bn_lib.c:431)
==9721==    by 0xBC26FF6: BN_set_bit (bn_lib.c:736)
==9721==    by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494)
==9721==    by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544)
==9721==    by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763)
==9721==    by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554)
==9721==    by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111)

I searched in this forum. I found a post reporting the same issue, but no
resolution provided -
http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854.

I wonder if anyone knows how to resolve this issue? Any help is appreciated.

Wang



Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Wang
The product can be build in threaded or non-threaded mode. The memory leak
can be detected only in threaded mode. Hence I think I hit the same issue
reported by Thomas in 2012.

"One thing I noticed is that all goes well if I cause the code to
run sequentially (e.g. cause requests to come one ater another). Yet it
starts eating up memory like crazy if I cause several (HTTPS) requests
to come at once. "
http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854.

Don't understand why this issue is not encountered by other users and why it
has not been fixed for so many years.


Thanks,
Wang





--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

OpenSSL - User mailing list
http://openssl.6102.n7.nabble.com/Memory-issues-with-ssl-handshake-td20851.html#a20854.
   
➢     Don't understand why this issue is not encountered by other users and why it
    has not been fixed for so many years.
   
The first part answer the second.  It is not encountered by others, so there might not be anything in OpenSSL to fix.  Can you use valgrind or something, to see where the memory is being leaked?

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Wang
In reply to this post by Wang
Hello Rich,

Thank you for trying to help.

My product is running on Linux. The following leak was detected by Valgrind.
Valgrind only reportes
the leak in threaded mode. I run 'top' on linux to monitor the memory usage
of my product. I can see the memory usage increases quickly.

==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of
1,294
==9721==    at 0x4A0817C: malloc (vg_replace_malloc.c:298)
==9721==    by 0x5B29CD0: comn_malloc (comalloc.c:28)
==9721==    by 0x58E7DD2: comn__csi_malloc (netenc2.c:52)
==9721==    by 0xBBC37EA: local_malloc (csi_provider_common.c:624)
==9721==    by 0xBC1747F: default_malloc_ex (mem.c:79)
==9721==    by 0xBC17BA6: CRYPTO_malloc (mem.c:350)
==9721==    by 0xBC2648F: bn_expand_internal (bn_lib.c:303)
==9721==    by 0xBC266AA: bn_expand2 (bn_lib.c:431)
==9721==    by 0xBC26FF6: BN_set_bit (bn_lib.c:736)
==9721==    by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494)
==9721==    by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544)
==9721==    by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763)
==9721==    by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554)
==9721==    by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111)

Regards,
Wang



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Matt Caswell-2


On 07/11/17 10:01, Wang wrote:

> Hello Rich,
>
> Thank you for trying to help.
>
> My product is running on Linux. The following leak was detected by Valgrind.
> Valgrind only reportes
> the leak in threaded mode. I run 'top' on linux to monitor the memory usage
> of my product. I can see the memory usage increases quickly.
>
> ==9721== 520 bytes in 1 blocks are indirectly lost in loss record 1,178 of
> 1,294
> ==9721==    at 0x4A0817C: malloc (vg_replace_malloc.c:298)
> ==9721==    by 0x5B29CD0: comn_malloc (comalloc.c:28)
> ==9721==    by 0x58E7DD2: comn__csi_malloc (netenc2.c:52)
> ==9721==    by 0xBBC37EA: local_malloc (csi_provider_common.c:624)
> ==9721==    by 0xBC1747F: default_malloc_ex (mem.c:79)
> ==9721==    by 0xBC17BA6: CRYPTO_malloc (mem.c:350)
> ==9721==    by 0xBC2648F: bn_expand_internal (bn_lib.c:303)
> ==9721==    by 0xBC266AA: bn_expand2 (bn_lib.c:431)
> ==9721==    by 0xBC26FF6: BN_set_bit (bn_lib.c:736)
> ==9721==    by 0xBCE0880: BN_MONT_CTX_set (bn_mont.c:494)
> ==9721==    by 0xBCE0A2F: BN_MONT_CTX_set_locked (bn_mont.c:544)
> ==9721==    by 0xBCED0C0: RSA_eay_mod_exp (rsa_eay.c:763)
> ==9721==    by 0xBCEC747: RSA_eay_private_decrypt (rsa_eay.c:554)
> ==9721==    by 0xBC3B7DE: RSA_private_decrypt (rsa_crpt.c:111)

Is this the "bottom" of the OpenSSL stack? i.e. your application calls
RSA_private_decrypt() directly? Do you share a single RSA object across
multiple threads?

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

OpenSSL - User mailing list
In reply to this post by Wang
There is something strange with the RSA private key or it’s BN_CONT object.  Are you sure that you are properly releasing all OpenSSL objecdts in your code?    

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Wang
In reply to this post by Matt Caswell-2
Hello Matt,

Thank you for trying to help.

>>>Is this the "bottom" of the OpenSSL stack? i.e. your application calls
>>>RSA_private_decrypt() directly?
Yes, it does.

>>>Do you share a single RSA object across multiple threads?
Yes, my application shares a single RSA object across many concurrent
threads. Namely RSA_private_decrypt()  is called with the same RSA object
concurrently across many threads.

Does this cause any issue? I checked OpenSSL document, but didn't find
anything related to this kind of restriction
(https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html). Or
this restriction is undocumented?

Regards,
Wang




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Matt Caswell-2


On 08/11/17 09:47, Wang wrote:

> Hello Matt,
>
> Thank you for trying to help.
>
>>>> Is this the "bottom" of the OpenSSL stack? i.e. your application calls
>>>> RSA_private_decrypt() directly?
> Yes, it does.
>
>>>> Do you share a single RSA object across multiple threads?
> Yes, my application shares a single RSA object across many concurrent
> threads. Namely RSA_private_decrypt()  is called with the same RSA object
> concurrently across many threads.
>
> Does this cause any issue? I checked OpenSSL document, but didn't find
> anything related to this kind of restriction
> (https://www.openssl.org/docs/manmaster/man3/RSA_public_encrypt.html). Or
> this restriction is undocumented?

https://www.openssl.org/docs/faq.html#PROG1

From the FAQ:

"1. Is OpenSSL thread-safe?

Yes but with some limitations; for example, an SSL connection cannot be
used concurrently by multiple threads. This is true for most OpenSSL
objects.

..."

This is also true for the RSA object. Temporary, thread specific
blinding state is held in the RSA object so it cannot be shared across
multiple threads.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Wang
In reply to this post by OpenSSL - User mailing list
Thanks again, Rich.

>>>There is something strange with the RSA private key or it’s BN_CONT
object.  
>>>Are you sure that you are properly releasing all OpenSSL objecdts in your
code?    
My application is a server. When it is initialized it calls RSA_new() to
allocate a RSA object. When the server is running, it keeps accepting
concurrent connection requests from many clients. When handling a connection
request it calls RSA_private_decrypt() to decrypt the encrypted password.
What a client does is to connect to the server and then disconnect at once.
Hence it takes very little time for each client. The RSA object is not
released until the server is shutdown.

Regards,
Wang



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Potential memory leak in RSA_private_decrypt

Wang
In reply to this post by Matt Caswell-2
This is very important information. Thank you very much, Matt.

I will update the code of my product and test if it resolves my issue. If it
does, I will post my feedback here. Hence other users can aviod the same
issue.

My product is complex and I have other things to do, so it may take a few
days.

Regards,
Wang



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users