Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

We have set SSL_CTX_set_session_cache_mode(ctx, /*SSL_SESS_CACHE_SERVER */ 
SSL_SESS_CACHE_OFF); 

Do you observe the same behavior with s_server app when we have cache mode set 
as SSL_SES_CACHE_OFF?

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Monday, March 27, 2017 3:04 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Hi Darshan

The behaviour you are seeing is not particularly surprising and does not 
indicate a memory leak. s_server maintains a cache of sessions from previous 
connections to enable the resumption capability. Since your s_client loop isn't 
resuming it creates a new session every time (which contains the client 
certificate), so I would expect the memory to grow.

To confirm there are no leaks I ran s_server through valgrind and ran your 
s_client loop. I actually *did* find a minor leak - but it does not grow over 
time and is constant no matter how many connections are made.
It only affects the command line apps and is also quite small (64 bytes on my 
machine). Fix here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3040=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU=VTPuVxG9-V4MA6C5eMla9AZ1hS3cGGFkl6PN3R0bAyA=
 

This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0 (probably 
because of the new auto-deinit capability).

Once the above patch was applied running s_server through valgrind with your 
s_client loop gives me:


CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
  71 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
  70 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
==15312==
==15312== HEAP SUMMARY:
==15312== in use at exit: 0 bytes in 0 blocks
==15312==   total heap usage: 230,141 allocs, 230,141 frees, 19,200,644
bytes allocated
==15312==
==15312== All heap blocks were freed -- no leaks are possible ==15312== 
==15312== For counts of detected and suppressed errors, rerun with: -v 
==15312== Use --track-origins=yes to see where uninitialised values come from 
==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0 from 0)


Matt



On 27/03/17 09:40, Mody, Darshan (Darshan) wrote:
> Matt, Richard,
> 
> I have not created any patch. Instead I am using s_server app provided 
> from Openssl. Below is the server side command run
> 
> openssl s_server -accept  -key  -cert 
>  -CAfile  CA>  -verify 
> 
> On the client side I am running script below
> 
> #/bin/sh
> 
> while [ 1 ]
> do
>  openssl s_client -connect : -cert  client certificate not trusted by server> -key  certificate key> &>/dev/null done
> 
> Running the client once and printing the results showed the cipher selected 
> was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of 
> openssl. 
> 
> I find that the server started leaking was leaking. Check the Resident memory 
> and the CPU. Resident memory increases after every 3 second. When I had 
> stopped the client traffic the resident memory did not increase however it 
> did not returned back to what it was earlier. Hope this will help to 
> reproduce the issue.
> 
> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   3924288k total,  3757716k used,   166572k free,78200k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl
> 
> 
> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:   3924288k total,  3757856k used,   166432k free,78208k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl
> 
> 
> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
&

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

Hi Darshan

The behaviour you are seeing is not particularly surprising and does not
indicate a memory leak. s_server maintains a cache of sessions from
previous connections to enable the resumption capability. Since your
s_client loop isn't resuming it creates a new session every time (which
contains the client certificate), so I would expect the memory to grow.

To confirm there are no leaks I ran s_server through valgrind and ran
your s_client loop. I actually *did* find a minor leak - but it does not
grow over time and is constant no matter how many connections are made.
It only affects the command line apps and is also quite small (64 bytes
on my machine). Fix here:

https://github.com/openssl/openssl/pull/3040

This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0
(probably because of the new auto-deinit capability).

Once the above patch was applied running s_server through valgrind with
your s_client loop gives me:


CONNECTION CLOSED
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
  71 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
  70 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)
==15312==
==15312== HEAP SUMMARY:
==15312== in use at exit: 0 bytes in 0 blocks
==15312==   total heap usage: 230,141 allocs, 230,141 frees, 19,200,644
bytes allocated
==15312==
==15312== All heap blocks were freed -- no leaks are possible
==15312==
==15312== For counts of detected and suppressed errors, rerun with: -v
==15312== Use --track-origins=yes to see where uninitialised values come
from
==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0
from 0)


Matt



On 27/03/17 09:40, Mody, Darshan (Darshan) wrote:
> Matt, Richard,
> 
> I have not created any patch. Instead I am using s_server app provided from 
> Openssl. Below is the server side command run
> 
> openssl s_server -accept  -key  -cert  signed by custom CA> -CAfile   -verify  signed CA>
> 
> On the client side I am running script below
> 
> #/bin/sh
> 
> while [ 1 ]
> do
>  openssl s_client -connect : -cert  certificate not trusted by server> -key  
> &>/dev/null
> done
> 
> Running the client once and printing the results showed the cipher selected 
> was ECDHE cipher.  I believe there is inherent leak in the ECDHE side of 
> openssl. 
> 
> I find that the server started leaking was leaking. Check the Resident memory 
> and the CPU. Resident memory increases after every 3 second. When I had 
> stopped the client traffic the resident memory did not increase however it 
> did not returned back to what it was earlier. Hope this will help to 
> reproduce the issue.
> 
> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  0.6%us,  0.1%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
> Mem:   3924288k total,  3757716k used,   166572k free,78200k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219736k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3528 2740 S  0.0  0.1   0:00.00 openssl
> 
> 
> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 zombie
> Cpu(s):  1.6%us,  0.9%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:   3924288k total,  3757856k used,   166432k free,78208k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3532 2740 R  4.3  0.1   0:00.13 openssl
> 
> 
> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.6%us,  0.8%sy,  0.1%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
> Mem:   3924288k total,  3757980k used,   166308k free,78232k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3544 2740 S  7.0  0.1   0:00.34 openssl
> 
> 
> top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 0.06, 0.08
> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
> Cpu(s):  2.1%us,  1.1%sy,  0.0%ni, 96.5%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
> Mem:   3924288k total,  3757964k used,   166324k free,78248k buffers
> Swap:  8388604k total,   999556k used,  7389048k fre

Re: [openssl-dev] Memory leak in application when we use ECDH

[Richard Levitte]

 3708 2740 S 11.3  0.1   0:03.10 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:17:13 up 46 days,  1:30,  2 users,  load average: 0.02, 
0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.6%us,  1.1%sy,  0.0%ni, 94.5%id,  0.0%wa,  0.0%hi,  
0.8%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758476k used,   165812k free,78376k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219920k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 40016 3728 2740 S 10.7  0.1   0:03.42 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:17:16 up 46 days,  1:30,  2 users,  load average: 0.02, 
0.06, 0.07
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.8%us,  1.3%sy,  0.0%ni, 93.3%id,  0.0%wa,  0.0%hi,  
1.7%si,  0.0%st
darshanmody> Mem:   3924288k total,  3759824k used,   164464k free,78384k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219920k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 40124 3748 2740 S 11.3  0.1   0:03.76 
openssl
darshanmody> 
darshanmody> ---
darshanmody> 
darshanmody> top - 10:23:10 up 46 days,  1:36,  2 users,  load average: 0.03, 
0.05, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.6%us,  1.3%sy,  0.1%ni, 94.4%id,  0.0%wa,  0.0%hi,  
0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756048k used,   168240k free,75888k 
buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216576k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 42392 6048 2740 S 10.7  0.2   0:41.95 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:23:13 up 46 days,  1:36,  2 users,  load average: 0.02, 
0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.2%us,  1.3%sy,  0.0%ni, 94.8%id,  0.0%wa,  0.0%hi,  
0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756064k used,   168224k free,75904k 
buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216572k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 42392 6068 2740 S 10.7  0.2   0:42.27 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:23:16 up 46 days,  1:36,  2 users,  load average: 0.02, 
0.04, 0.06
darshanmody> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.2%us,  1.3%sy,  0.1%ni, 94.9%id,  0.0%wa,  0.0%hi,  
0.4%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756188k used,   168100k free,75912k 
buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216572k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 42392 6088 2740 R 11.0  0.2   0:42.60 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:23:19 up 46 days,  1:36,  2 users,  load average: 0.02, 
0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  3.1%us,  1.2%sy,  1.6%ni, 93.5%id,  0.0%wa,  0.0%hi,  
0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756528k used,   167760k free,75920k 
buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216584k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 42392 6108 2740 S 10.7  0.2   0:42.92 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 
0.04, 0.06
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  
0.6%si,  0.0%st
darshanmody> Mem:   3924288k total,  3756924k used,   167364k free,75952k 
buffers
darshanmody> Swap:  8388604k total,   998972k used,  7389632k free,   216600k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 42500 6124 2740 S 10.3  0.2   0:43.23 
openssl
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

0.2   0:42.92 openssl


top - 10:23:22 up 46 days,  1:36,  2 users,  load average: 0.02, 0.04, 0.06
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.1%us,  4.6%sy, 20.2%ni, 63.6%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3756924k used,   167364k free,75952k buffers
Swap:  8388604k total,   998972k used,  7389632k free,   216600k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
27303 root  20   0 42500 6124 2740 S 10.3  0.2   0:43.23 openssl

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, 
Darshan (Darshan)
Sent: Thursday, March 23, 2017 7:40 PM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Thanks Richard and Matt,

I will patch it and send the patch. It will take me couple of days.

Regards
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give 
us that patch.

The reason is that we can't know what assumptions you're going with in your 
callback or application, so if we code an example together, it will be with Our 
conditions, not yours, and therefore a pretty bad method to figure this out.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 
23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)" <darshanm...@avaya.com> 
said:

darshanmody> Matt,
darshanmody> 
darshanmody> Below is the scenario.
darshanmody> 
darshanmody> 1. Have server open a listen socket which always validates the 
client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY 
passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody> 
darshanmody> In course of time the app running the server has been leaking. 
Even after accounting for the EC_KEY passed by the server app to openssl we 
find there seems to be leak. Further investigation on the core dumps generated 
from the server app shows that it has the certificates from the client saved.
darshanmody> 
darshanmody> Hope this helps
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org]
darshanmody> On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: openssl-dev@openssl.org
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when 
darshanmody> we use ECDH
darshanmody> 
darshanmody> 
darshanmody> 
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> > 
darshanmody> > What we did is to create a TLS connection and with 
darshanmody> > invalid certificates from the client and server on 
darshanmody> > verification would reject the certificate. The cipher 
darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> > 
darshanmody> > This was done with load (multiple while 1 script trying 
darshanmody> > to connect to server using invalid certificates and in 
darshanmody> > course of time the memory was increasing).
darshanmody> 
darshanmody> Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.
darshanmody> 
darshanmody> Matt
darshanmody> 
darshanmody> 
darshanmody> > 
darshanmody> > Thanks Darshan
darshanmody> > 
darshanmody> > -Original Message- From: openssl-dev 
darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of 
darshanmody> > Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: 
darshanmody> > openssl-dev@openssl.org
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application 
darshanmody> > when we use ECDH
darshanmody> > 
darshanmody> > 
darshanmody> > 
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >> 
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started a

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Thanks Richard and Matt,

I will patch it and send the patch. It will take me couple of days.

Regards
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard 
Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give 
us that patch.

The reason is that we can't know what assumptions you're going with in your 
callback or application, so if we code an example together, it will be with Our 
conditions, not yours, and therefore a pretty bad method to figure this out.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 
23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)" <darshanm...@avaya.com> 
said:

darshanmody> Matt,
darshanmody> 
darshanmody> Below is the scenario.
darshanmody> 
darshanmody> 1. Have server open a listen socket which always validates the 
client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY 
passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody> 
darshanmody> In course of time the app running the server has been leaking. 
Even after accounting for the EC_KEY passed by the server app to openssl we 
find there seems to be leak. Further investigation on the core dumps generated 
from the server app shows that it has the certificates from the client saved.
darshanmody> 
darshanmody> Hope this helps
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] 
darshanmody> On Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: openssl-dev@openssl.org
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when 
darshanmody> we use ECDH
darshanmody> 
darshanmody> 
darshanmody> 
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> > 
darshanmody> > What we did is to create a TLS connection and with 
darshanmody> > invalid certificates from the client and server on 
darshanmody> > verification would reject the certificate. The cipher 
darshanmody> > negotiated was ECDHE cipher between client and server.
darshanmody> > 
darshanmody> > This was done with load (multiple while 1 script trying 
darshanmody> > to connect to server using invalid certificates and in 
darshanmody> > course of time the memory was increasing).
darshanmody> 
darshanmody> Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.
darshanmody> 
darshanmody> Matt
darshanmody> 
darshanmody> 
darshanmody> > 
darshanmody> > Thanks Darshan
darshanmody> > 
darshanmody> > -Original Message- From: openssl-dev 
darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of 
darshanmody> > Matt Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: 
darshanmody> > openssl-dev@openssl.org
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application 
darshanmody> > when we use ECDH
darshanmody> > 
darshanmody> > 
darshanmody> > 
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >> 
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC 
darshanmody> >> with callback SSL_set_tmp_ecdh_callback().
darshanmody> >> 
darshanmody> >> The core dump shows  the string data of the far-end 
certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> > 
darshanmody> > Are you able to create a simple reproducer demonstrating 
darshanmody> > the problem with the callback?
darshanmody> > 
darshanmody> > Matt
darshanmody> > 
darshanmody> --
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op
darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8
darshanmody> bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEb

Re: [openssl-dev] Memory leak in application when we use ECDH

[Richard Levitte]

I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c,
and give us that patch.

The reason is that we can't know what assumptions you're going with in
your callback or application, so if we code an example together, it
will be with Our conditions, not yours, and therefore a pretty bad
method to figure this out.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a107...@az-ffexmb03.global.avaya.com> on Thu, 
23 Mar 2017 13:47:10 +, "Mody, Darshan (Darshan)" <darshanm...@avaya.com> 
said:

darshanmody> Matt,
darshanmody> 
darshanmody> Below is the scenario.
darshanmody> 
darshanmody> 1. Have server open a listen socket which always validates the 
client certificate and chain.
darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY 
passed to openssl from app is cleaned up by the app.
darshanmody> 3. Connect client with certificates that server does not trust.
darshanmody> 4. The connections from client to server fails
darshanmody> 
darshanmody> In course of time the app running the server has been leaking. 
Even after accounting for the EC_KEY passed by the server app to openssl we 
find there seems to be leak. Further investigation on the core dumps generated 
from the server app shows that it has the certificates from the client saved.
darshanmody> 
darshanmody> Hope this helps
darshanmody> 
darshanmody> Thanks
darshanmody> Darshan 
darshanmody> 
darshanmody> -Original Message-
darshanmody> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On 
Behalf Of Matt Caswell
darshanmody> Sent: Thursday, March 23, 2017 6:55 PM
darshanmody> To: openssl-dev@openssl.org
darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use 
ECDH
darshanmody> 
darshanmody> 
darshanmody> 
darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
darshanmody> > Can you further elaborate?
darshanmody> > 
darshanmody> > What we did is to create a TLS connection and with invalid 
darshanmody> > certificates from the client and server on verification would 
reject 
darshanmody> > the certificate. The cipher negotiated was ECDHE cipher between 
client 
darshanmody> > and server.
darshanmody> > 
darshanmody> > This was done with load (multiple while 1 script trying to 
connect to 
darshanmody> > server using invalid certificates and in course of time the 
memory was 
darshanmody> > increasing).
darshanmody> 
darshanmody> Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.
darshanmody> 
darshanmody> Matt
darshanmody> 
darshanmody> 
darshanmody> > 
darshanmody> > Thanks Darshan
darshanmody> > 
darshanmody> > -Original Message- From: openssl-dev 
darshanmody> > [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: 
openssl-dev@openssl.org
darshanmody> > Subject: Re: [openssl-dev] Memory leak in application when we 
use ECDH
darshanmody> > 
darshanmody> > 
darshanmody> > 
darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
darshanmody> >> Matt,
darshanmody> >> 
darshanmody> >> Even after accounting for the EC_KEY we still observe some leak.
darshanmody> >> The leak started after we started using supporting EC with
darshanmody> >> callback SSL_set_tmp_ecdh_callback().
darshanmody> >> 
darshanmody> >> The core dump shows  the string data of the far-end 
certificates.
darshanmody> >> I cannot pin point  the code in openssl with this regard.
darshanmody> > 
darshanmody> > Are you able to create a simple reproducer demonstrating the 
problem 
darshanmody> > with the callback?
darshanmody> > 
darshanmody> > Matt
darshanmody> > 
darshanmody> -- 
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ=
 
darshanmody> -- 
darshanmody> openssl-dev mailing list
darshanmody> To unsubscribe: 
https://mta.openssl.org/mailman/listinfo/openssl-dev
darshanmody> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

Below is the scenario.

1. Have server open a listen socket which always validates the client 
certificate and chain.
2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl 
from app is cleaned up by the app.
3. Connect client with certificates that server does not trust.
4. The connections from client to server fails

In course of time the app running the server has been leaking. Even after 
accounting for the EC_KEY passed by the server app to openssl we find there 
seems to be leak. Further investigation on the core dumps generated from the 
server app shows that it has the certificates from the client saved.

Hope this helps

Thanks
Darshan 

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 6:55 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> Can you further elaborate?
> 
> What we did is to create a TLS connection and with invalid 
> certificates from the client and server on verification would reject 
> the certificate. The cipher negotiated was ECDHE cipher between client 
> and server.
> 
> This was done with load (multiple while 1 script trying to connect to 
> server using invalid certificates and in course of time the memory was 
> increasing).

Without being able to recreate the problem its going to be very 
difficult/impossible for us to fix it (assuming the problem is in OpenSSl 
itself). We would need some simple reproducer code that demonstrates the 
problem occurring.

Matt


> 
> Thanks Darshan
> 
> -Original Message- From: openssl-dev 
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell
> Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>> 
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>> 
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
> 
> Are you able to create a simple reproducer demonstrating the problem 
> with the callback?
> 
> Matt
> 
-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> Can you further elaborate?
> 
> What we did is to create a TLS connection and with invalid
> certificates from the client and server on verification would reject
> the certificate. The cipher negotiated was ECDHE cipher between
> client and server.
> 
> This was done with load (multiple while 1 script trying to connect to
> server using invalid certificates and in course of time the memory
> was increasing).

Without being able to recreate the problem its going to be very
difficult/impossible for us to fix it (assuming the problem is in
OpenSSl itself). We would need some simple reproducer code that
demonstrates the problem occurring.

Matt


> 
> Thanks Darshan
> 
> -Original Message- From: openssl-dev
> [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt Caswell 
> Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev@openssl.org 
> Subject: Re: [openssl-dev] Memory leak in application when we use
> ECDH
> 
> 
> 
> On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
>> Matt,
>> 
>> Even after accounting for the EC_KEY we still observe some leak.
>> The leak started after we started using supporting EC with
>> callback SSL_set_tmp_ecdh_callback().
>> 
>> The core dump shows  the string data of the far-end certificates.
>> I cannot pin point  the code in openssl with this regard.
> 
> Are you able to create a simple reproducer demonstrating the problem 
> with the callback?
> 
> Matt
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Can you further elaborate? 

What we did is to create a TLS connection and with invalid certificates from 
the client and server on verification would reject the certificate. The cipher 
negotiated was ECDHE cipher between client and server.

This was done with load (multiple while 1 script trying to connect to server 
using invalid certificates and in course of time the memory was increasing). 

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 4:09 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
> 
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

-- 
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=bLfMhjtc7o6YlbbKPhSGSKPuhTJsYubiC_LV17YO3do=CIdcV48IKxBzbTWaEpB4zcKDD76FwUj3wuMFrxa50UY=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
> 
> The core dump shows  the string data of the far-end certificates. I
> cannot pin point  the code in openssl with this regard.

Are you able to create a simple reproducer demonstrating the problem
with the callback?

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

Even after accounting for the EC_KEY we still observe some leak. The leak 
started after we started using supporting EC with callback 
SSL_set_tmp_ecdh_callback().

The core dump shows  the string data of the far-end certificates. I cannot pin 
point  the code in openssl with this regard.

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Thursday, March 23, 2017 3:31 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> But openssl does not release the memory when it has duplicated the EC 
> Key which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no 
"official" description of the memory management semantics of this function (and 
like I said it has been removed from later versions of OpenSSL altogether so it 
is unlikely to ever get documented). However my interpretation of the way the 
code is written is that this is a deliberate design choice, i.e. it is 
deliberately left to the the application to mange this memory. Presumably 
multiple invocations across multiple connections could return the same value so 
it would be inappropriate for OpenSSL to free it.

Matt



> 
>/* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> if (s->cert->ecdh_tmp_auto)
> ecdh = ecdhp;
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> 
> Thanks
> Darshan
> 
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf 
> Of Matt Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>> if (s->s3->tmp.ecdh != NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>ERR_R_INTERNAL_ERROR);
>> goto err;
>> }
>>
>> But this is a "should not happen" scenario - so there is another bug 
>> if that is happening - and you would see "internal error" messages on 
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp 
>> against NULL which seems redundant (but otherwise harmless):
>>
>> if (ecdhp == NULL) {
>> al = SSL_AD_HANDSHAKE_FAILURE;
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>SSL_R_MISSING_TMP_ECDH_KEY);
>> goto f_err;
>> }
>>
>> ...
>>
>> /* Duplicate the ECDH structure. */
>> if (ecdhp == NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>> goto err;
>> }
> 
> Fix for the above issues (which is unlikely to solve your problem) is here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss
> l_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7I
> nzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuk
> i2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
> 
> Matt
> 
> --
> openssl-dev mailing list
> To unsubscribe: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m
> ailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEU
> LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi
> -yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
> 
--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=jvDI18EtBUGVhF0dlpzP1E0w75ZPjyBprI47vr1-QlA=QwfWOZbsFqgCiO23c3Z6HmnkCgfsT94LaHQSoaQLIFM=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
> 
> But openssl does not release the memory when it has duplicated the EC Key 
> which comes from the application

You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so there is no
"official" description of the memory management semantics of this
function (and like I said it has been removed from later versions of
OpenSSL altogether so it is unlikely to ever get documented). However my
interpretation of the way the code is written is that this is a
deliberate design choice, i.e. it is deliberately left to the the
application to mange this memory. Presumably multiple invocations across
multiple connections could return the same value so it would be
inappropriate for OpenSSL to free it.

Matt



> 
>/* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> if (s->cert->ecdh_tmp_auto)
> ecdh = ecdhp;
> else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }
> 
> Thanks
> Darshan
> 
> -Original Message-
> From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
> Caswell
> Sent: Tuesday, March 21, 2017 3:28 PM
> To: openssl-dev@openssl.org
> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH
> 
> 
> 
> On 21/03/17 09:46, Matt Caswell wrote:
>>
>> There is a potential leak in this case:
>>
>> if (s->s3->tmp.ecdh != NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>ERR_R_INTERNAL_ERROR);
>> goto err;
>> }
>>
>> But this is a "should not happen" scenario - so there is another bug 
>> if that is happening - and you would see "internal error" messages on 
>> the error stack.
>>
>> Another slight oddity in this code is the double check of ecdhp 
>> against NULL which seems redundant (but otherwise harmless):
>>
>> if (ecdhp == NULL) {
>> al = SSL_AD_HANDSHAKE_FAILURE;
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>>SSL_R_MISSING_TMP_ECDH_KEY);
>> goto f_err;
>> }
>>
>> ...
>>
>> /* Duplicate the ECDH structure. */
>> if (ecdhp == NULL) {
>> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
>> goto err;
>> }
> 
> Fix for the above issues (which is unlikely to solve your problem) is here:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
>  
> 
> Matt
> 
> --
> openssl-dev mailing list
> To unsubscribe: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
>  
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Should not openssl release memory from app.

Some like below

/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else {
if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
else {
/* Release memory from cb */
If (NULL !=ecdhp) {
EC_KEY_free(ecdhp);
}
}
}

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, 
Darshan (Darshan)
Sent: Thursday, March 23, 2017 10:06 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill)
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH

Matt,

But openssl does not release the memory when it has duplicated the EC Key which 
comes from the application

   /* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 21/03/17 09:46, Matt Caswell wrote:
> 
> There is a potential leak in this case:
> 
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
> 
> But this is a "should not happen" scenario - so there is another bug 
> if that is happening - and you would see "internal error" messages on 
> the error stack.
> 
> Another slight oddity in this code is the double check of ecdhp 
> against NULL which seems redundant (but otherwise harmless):
> 
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
> 
> ...
> 
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
 

Matt

--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=ItYO5obXpUhcVAqtr-HAnmatrYOEJ-EpjZhn-eCTsyg=EYfD8Wpi4Eji8E2PwNF9obPY-g4EXP5FXF1AzbJtMGU=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Matt,

But openssl does not release the memory when it has duplicated the EC Key which 
comes from the application

   /* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { 
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

Thanks
Darshan

-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Matt 
Caswell
Sent: Tuesday, March 21, 2017 3:28 PM
To: openssl-dev@openssl.org
Subject: Re: [openssl-dev] Memory leak in application when we use ECDH



On 21/03/17 09:46, Matt Caswell wrote:
> 
> There is a potential leak in this case:
> 
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
> 
> But this is a "should not happen" scenario - so there is another bug 
> if that is happening - and you would see "internal error" messages on 
> the error stack.
> 
> Another slight oddity in this code is the double check of ecdhp 
> against NULL which seems redundant (but otherwise harmless):
> 
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
> 
> ...
> 
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no=
 

Matt

--
openssl-dev mailing list
To unsubscribe: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev=DwICAg=BFpWQw8bsuKpl1SgiZH64Q=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs=
 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 21/03/17 09:46, Matt Caswell wrote:
> 
> There is a potential leak in this case:
> 
> if (s->s3->tmp.ecdh != NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>ERR_R_INTERNAL_ERROR);
> goto err;
> }
> 
> But this is a "should not happen" scenario - so there is another bug if
> that is happening - and you would see "internal error" messages on the
> error stack.
> 
> Another slight oddity in this code is the double check of ecdhp against
> NULL which seems redundant (but otherwise harmless):
> 
> if (ecdhp == NULL) {
> al = SSL_AD_HANDSHAKE_FAILURE;
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
>SSL_R_MISSING_TMP_ECDH_KEY);
> goto f_err;
> }
> 
> ...
> 
> /* Duplicate the ECDH structure. */
> if (ecdhp == NULL) {
> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
> goto err;
> }

Fix for the above issues (which is unlikely to solve your problem) is here:

https://github.com/openssl/openssl/pull/3003

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Matt Caswell]

On 15/03/17 05:44, Mody, Darshan (Darshan) wrote:
> Hi,
> 
> We have observed memory leak when we register for ECDH
> callback(SSL_set_tmp_ecdh_callback). While performing negative testing
> with load we find that the applications starts leaking memory.  
> 
> Further checking the Openssl implementation in the s3_srvr.c file
> (openssl version 1.0.2). I find that a pointer is not deleted after
> copying EC_KEY from the application or EC_KEY_new being called.
> 
> I suspect the below code.

The code looks ok to me:

if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

s->s3->tmp.ecdh = ecdh;

After the EC_KEY_dup() call, the result is immediately assigned to
"s->s3->tmp.ecdh". This will get freed when you call SSL_free().
Similarly in the non-callback case.

There is a potential leak in this case:

if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_INTERNAL_ERROR);
goto err;
}

But this is a "should not happen" scenario - so there is another bug if
that is happening - and you would see "internal error" messages on the
error stack.

Another slight oddity in this code is the double check of ecdhp against
NULL which seems redundant (but otherwise harmless):

if (ecdhp == NULL) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_MISSING_TMP_ECDH_KEY);
goto f_err;
}

...

/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}


Also note that SSL_set_tmp_ecdh_callback() has been removed from OpenSSL
1.1.0 with this commit description:

commit 6f78b9e824c053d062188578635c575017b587c5
Author: Kurt Roeckx <k...@roeckx.be>
AuthorDate: Fri Dec 4 22:22:31 2015 +0100
Commit: Kurt Roeckx <k...@roeckx.be>
CommitDate: Fri Dec 4 22:22:31 2015 +0100

Remove support for SSL_{CTX_}set_tmp_ecdh_callback().

This only gets used to set a specific curve without actually
checking that the
peer supports it or not and can therefor result in handshake
failures that can
be avoided by selecting a different cipher.

Reviewed-by: Dr. Stephen Henson <st...@openssl.org>


Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Hi,

Can anyone in the developer forum clarify whether there is an issue here?

Thanks
Darshan

From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Mody, 
Darshan (Darshan)
Sent: Wednesday, March 15, 2017 11:15 AM
To: openssl-dev@openssl.org
Cc: Bahr, William G (Bill); Vaquero, Alejandro (Alejandro)
Subject: [openssl-dev] Memory leak in application when we use ECDH

Hi,

We have observed memory leak when we register for ECDH 
callback(SSL_set_tmp_ecdh_callback). While performing negative testing with 
load we find that the applications starts leaking memory.

Further checking the Openssl implementation in the s3_srvr.c file (openssl 
version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from 
the application or EC_KEY_new being called.

I suspect the below code.

if (type & SSL_kEECDH) {
const EC_GROUP *group;

ecdhp = cert->ecdh_tmp;
if (s->cert->ecdh_tmp_auto) {
/* Get NID of appropriate shared curve */
int nid = tls1_shared_curve(s, -2);
if (nid != NID_undef)
ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory 
allocated in this case is not de-allocated.
} else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {
ecdhp = s->cert->ecdh_tmp_cb(s, 
  <-- Application is responsible for the EC_KEY and its 
memory
 SSL_C_IS_EXPORT(s->s3->
 tmp.new_cipher),
 SSL_C_EXPORT_PKEYLENGTH(s->
 
s3->tmp.new_cipher));
}
if (ecdhp == NULL) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_MISSING_TMP_ECDH_KEY);
goto f_err;
}

if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_INTERNAL_ERROR);
goto err;
}

/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {  
  <-- Once the key is duplicated the memory for the 
application should be released?
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

s->s3->tmp.ecdh = ecdh;
if ((EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL) ||
(s->options & SSL_OP_SINGLE_ECDH_USE)) {
if (!EC_KEY_generate_key(ecdh)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_ECDH_LIB);
goto err;
}
}

if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||
(EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
(EC_GROUP_get_degree(group) > 163)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);
goto err;
}

/*
 * XXX: For now, we only support ephemeral ECDH keys over named
 * (not generic) curves. For supported named curves, curve_id is
 * non-zero.
 */
if ((curve_id =
 tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))
== 0) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);
goto err;
}

/*
 * Encode the public key. First check the size of encoding and
 * allocate memory accordingly.
 */
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
NULL, 0, NULL);

encodedPoint = (unsigned char *)
OPENSSL_malloc(encodedlen * sizeof(unsigned char));
bn_ctx = BN_CTX_new();
if ((encoded

[openssl-dev] Memory leak in application when we use ECDH

[Mody, Darshan (Darshan)]

Hi,

We have observed memory leak when we register for ECDH 
callback(SSL_set_tmp_ecdh_callback). While performing negative testing with 
load we find that the applications starts leaking memory.

Further checking the Openssl implementation in the s3_srvr.c file (openssl 
version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from 
the application or EC_KEY_new being called.

I suspect the below code.

if (type & SSL_kEECDH) {
const EC_GROUP *group;

ecdhp = cert->ecdh_tmp;
if (s->cert->ecdh_tmp_auto) {
/* Get NID of appropriate shared curve */
int nid = tls1_shared_curve(s, -2);
if (nid != NID_undef)
ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory 
allocated in this case is not de-allocated.
} else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) {
ecdhp = s->cert->ecdh_tmp_cb(s, 
  <-- Application is responsible for the EC_KEY and its 
memory
 SSL_C_IS_EXPORT(s->s3->
 tmp.new_cipher),
 SSL_C_EXPORT_PKEYLENGTH(s->
 
s3->tmp.new_cipher));
}
if (ecdhp == NULL) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_MISSING_TMP_ECDH_KEY);
goto f_err;
}

if (s->s3->tmp.ecdh != NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_INTERNAL_ERROR);
goto err;
}

/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if (s->cert->ecdh_tmp_auto)
ecdh = ecdhp;
else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) {  
  <-- Once the key is duplicated the memory for the 
application should be released?
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

s->s3->tmp.ecdh = ecdh;
if ((EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL) ||
(s->options & SSL_OP_SINGLE_ECDH_USE)) {
if (!EC_KEY_generate_key(ecdh)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_ECDH_LIB);
goto err;
}
}

if (((group = EC_KEY_get0_group(ecdh)) == NULL) ||
(EC_KEY_get0_public_key(ecdh) == NULL) ||
(EC_KEY_get0_private_key(ecdh) == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}

if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) &&
(EC_GROUP_get_degree(group) > 163)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER);
goto err;
}

/*
 * XXX: For now, we only support ephemeral ECDH keys over named
 * (not generic) curves. For supported named curves, curve_id is
 * non-zero.
 */
if ((curve_id =
 tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group)))
== 0) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   SSL_R_UNSUPPORTED_ELLIPTIC_CURVE);
goto err;
}

/*
 * Encode the public key. First check the size of encoding and
 * allocate memory accordingly.
 */
encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
NULL, 0, NULL);

encodedPoint = (unsigned char *)
OPENSSL_malloc(encodedlen * sizeof(unsigned char));
bn_ctx = BN_CTX_new();
if ((encodedPoint == NULL) || (bn_ctx == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
   ERR_R_MALLOC_FAILURE);
goto err;
}

encodedlen = EC_POINT_point2oct(group,
EC_KEY_get0_public_key(ecdh),
POINT_CONVERSION_UNCOMPRESSED,
 

Re: [openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free

[Martin Simmons]

I think your problem (and the stack overflow) is caused by using "CALLBACK" in
the 3 function typedefs.  Try using __cdecl instead of CALLBACK.

__Martin


> On Tue, 11 Oct 2016 16:15:24 +, Simone Sgualdini via RT said:
>
> 
> Hi,
> 
> 
> I'm writing a c++ server application that calls thounsands of times per 
> hour the rsa_new()
> and rsa_free() openssl functions.
> 
> After debugging a lot I discovered that "sometimes" (I'm not able to 
> tell a precise number) the rsa_free
> does not release properly the memory allocated by the rsa_new.
> In order to prove this I created the simple program below. If i run it, 
> i see the related working set
> going bigger and bigger, 4KB per second.
> 
> I'm using the 1.0.2.8 version of libeay32.dll and ssleay32.ddl under 
> windows 7 64 bit.
> 
> It this a known bug? I'm forgetting something?
> 
> Thanks in advance
> 
> Simone Sgualdini
> Italy
> 
> 
> //---
> 
> #include 
> 
> 
> #ifdef _cplusplus
> extern "C"
>{
> #endif
>  #include 
>  #include 
>  #include 
>#include 
>#include 
> #ifdef _cplusplus
>}
> #endif
> #pragma hdrstop
> 
> HMODULE libeay32DLL = NULL;
> HMODULE ssleay32DLL = NULL;
> 
> typedef RSA  *(CALLBACK *myRSA_new) (void);
> typedef void  (CALLBACK *myRSA_free) (RSA *r);
> typedef int   (CALLBACK *mySSL_library_init) (void);
> 
> myRSA_new_RSA_new= NULL;
> myRSA_free   _RSA_free   = NULL;
> mySSL_library_init   _SSL_library_init;
> 
> //---
> 
> #pragma argsused
> 
> int main(int argc, char* argv[])
> {
>RSA   *rsa;
>unsigned long count = 0;
> 
>libeay32DLL = LoadLibrary("libeay32.dll");
>ssleay32DLL = LoadLibrary("ssleay32.dll");
> 
>if(libeay32DLL && ssleay32DLL)
>  {
>_RSA_new= (myRSA_new) 
> GetProcAddress(libeay32DLL,"RSA_new");
>_RSA_free   = (myRSA_free) 
> GetProcAddress(libeay32DLL,"RSA_free");
>_SSL_library_init   = (mySSL_library_init) 
> GetProcAddress(ssleay32DLL,"SSL_library_init");
>  }
> 
>_SSL_library_init();
> 
>while(1)
>   {
> 
>if(++count %100 == 0)  // whitout this, I get a stack overflow 
> immediately
>   Sleep(1);
> 
> *_RSA_free(_RSA_new());*
>  }
> 
>return 0;
> }
> 
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4704
> Please log in as guest with password guest if prompted
> 
> -- 
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
> 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4704] Memory leak in rsa_new/rsa_free

[Simone Sgualdini via RT]

Hi,


I'm writing a c++ server application that calls thounsands of times per 
hour the rsa_new()
and rsa_free() openssl functions.

After debugging a lot I discovered that "sometimes" (I'm not able to 
tell a precise number) the rsa_free
does not release properly the memory allocated by the rsa_new.
In order to prove this I created the simple program below. If i run it, 
i see the related working set
going bigger and bigger, 4KB per second.

I'm using the 1.0.2.8 version of libeay32.dll and ssleay32.ddl under 
windows 7 64 bit.

It this a known bug? I'm forgetting something?

Thanks in advance

Simone Sgualdini
Italy


//---

#include 


#ifdef _cplusplus
extern "C"
   {
#endif
 #include 
 #include 
 #include 
   #include 
   #include 
#ifdef _cplusplus
   }
#endif
#pragma hdrstop

HMODULE libeay32DLL = NULL;
HMODULE ssleay32DLL = NULL;

typedef RSA  *(CALLBACK *myRSA_new) (void);
typedef void  (CALLBACK *myRSA_free) (RSA *r);
typedef int   (CALLBACK *mySSL_library_init) (void);

myRSA_new_RSA_new= NULL;
myRSA_free   _RSA_free   = NULL;
mySSL_library_init   _SSL_library_init;

//---

#pragma argsused

int main(int argc, char* argv[])
{
   RSA   *rsa;
   unsigned long count = 0;

   libeay32DLL = LoadLibrary("libeay32.dll");
   ssleay32DLL = LoadLibrary("ssleay32.dll");

   if(libeay32DLL && ssleay32DLL)
 {
   _RSA_new= (myRSA_new) 
GetProcAddress(libeay32DLL,"RSA_new");
   _RSA_free   = (myRSA_free) 
GetProcAddress(libeay32DLL,"RSA_free");
   _SSL_library_init   = (mySSL_library_init) 
GetProcAddress(ssleay32DLL,"SSL_library_init");
 }

   _SSL_library_init();

   while(1)
  {

   if(++count %100 == 0)  // whitout this, I get a stack overflow 
immediately
  Sleep(1);

*_RSA_free(_RSA_new());*
 }

   return 0;
}


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4704
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c

[Rich Salz via RT]

Seems to have been fixed some time ago. thanks.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4259
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

[Ramūnas Jurgilas via RT]

Thank you very much for the fix. 

Best regards,
Ramunas

> On May 7, 2016, at 12:07 AM, Stephen Henson via RT  wrote:
> 
> Fixed, thanks for the report.
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466
> Please log in as guest with password guest if prompted
> 


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4400] [PATCH] plug potential memory leak in OpenSSL 1.1 pre 4

[Matt Caswell via RT]

This patch doesn't look correct. I don't see a memory leak here.

Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4400
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

[Stephen Henson via RT]

Fixed, thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

[Stephen Henson via RT]

On Mon Mar 21 13:02:56 2016, ramunas.jurgi...@gmail.com wrote:
> I did write function which changes PKCS12 passphrase. I noticed that
> PKCS12_newpass function leaks memory. Memory leak disappears when
> commenting out line where is PKCS12_newpass func.
>
> Below I posted this code which I am using.
> I am using OpneSSL 1.0.2g version.
>
> Could you please give me information what I am doing wrong? Or it is
> known issue?
>

I can confirm there is a leak in that function and it's a bug in OpenSSL.
Looking into it.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509

[Emilia Käsper via RT]

X509_REQ_to_X509 returns a newly allocated X509 structure.

If you believe that it leaks somewhere else, then please reopen this ticket
with fully self-contained code, and a trace (e.g., from valgrind) showing where
the leak happens.

Emilia

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4433
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4465] PKCS12_newpass memory leak

[Ramūnas Jurgilas via RT]

I did write function which changes PKCS12 passphrase. I noticed that
PKCS12_newpass function leaks memory. Memory leak disappears when
commenting out line where is PKCS12_newpass func.

Below I posted this code which I am using.
I am using OpneSSL 1.0.2g version.

Could you please give me information what I am doing wrong? Or it is known
issue?

Bets regards,
Ramunas

- (NSData*)changePKCS12:(NSData*)p12Data
  oldPassphrase:(NSString*)oldPassphrase
  newPassphrase:(NSString*)newPassphrase {
OpenSSL_add_all_algorithms();
BIO *bp = NULL;
PKCS12 *p12 = NULL;
int status = 0;
do {
bp = BIO_new_mem_buf((void *)[p12Data bytes], (int)[p12Data
length]);

p12 = d2i_PKCS12_bio(bp, NULL);

// MEMORY LEAK in PKCS12_newpass
status = PKCS12_newpass(p12, (char *)[oldPassphrase UTF8String],
(char *)[newPassphrase UTF8String]);
} while (false);

if (p12) {
PKCS12_free(p12);
p12 = NULL;
}
if (bp) {
BIO_free_all(bp);
bp = NULL;
}
EVP_cleanup();
return NULL;
}

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4465
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4466] Memory leak in PKCS12_newpass function

[Ramūnas Jurgilas via RT]

I did write function which changes PKCS12 passphrase. I noticed that 
PKCS12_newpass function leaks memory. Memory leak disappears when commenting 
out line where is PKCS12_newpass func.

Below I posted this code which I am using.
I am using OpneSSL 1.0.2g version.

Could you please give me information what I am doing wrong? Or it is known 
issue?

Bets regards,
Ramunas

- (NSData*)changePKCS12:(NSData*)p12Data
  oldPassphrase:(NSString*)oldPassphrase
  newPassphrase:(NSString*)newPassphrase {
OpenSSL_add_all_algorithms();
BIO *bp = NULL;
PKCS12 *p12 = NULL;
int status = 0;
do {
bp = BIO_new_mem_buf((void *)[p12Data bytes], (int)[p12Data length]);

p12 = d2i_PKCS12_bio(bp, NULL);

// MEMORY LEAK in PKCS12_newpass
status = PKCS12_newpass(p12, (char *)[oldPassphrase UTF8String], (char 
*)[newPassphrase UTF8String]);
} while (false);

if (p12) {
PKCS12_free(p12);
p12 = NULL;
}
if (bp) {
BIO_free_all(bp);
bp = NULL;
}
EVP_cleanup();
return NULL;
}


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4466
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Memory leak in PKCS12_newpass function

[Ramūnas Jurgilas]

Hello OpenSSL Team,

I did write function which changes PKCS12 passphrase. I noticed that 
PKCS12_newpass function leaks memory. Memory leak disappears when commenting 
out line where is PKCS12_newpass func.

Below I posted this code which I am using.
I am using OpneSSL 1.0.2g version.

Could you please give me information what I am doing wrong? Or it is known 
issue?

Bets regards,
Ramunas

- (NSData*)changePKCS12:(NSData*)p12Data
  oldPassphrase:(NSString*)oldPassphrase
  newPassphrase:(NSString*)newPassphrase {
OpenSSL_add_all_algorithms();
BIO *bp = NULL;
PKCS12 *p12 = NULL;
int status = 0;
do {
bp = BIO_new_mem_buf((void *)[p12Data bytes], (int)[p12Data length]);

p12 = d2i_PKCS12_bio(bp, NULL);

// MEMORY LEAK in PKCS12_newpass
status = PKCS12_newpass(p12, (char *)[oldPassphrase UTF8String], (char 
*)[newPassphrase UTF8String]);
} while (false);

if (p12) {
PKCS12_free(p12);
p12 = NULL;
}
if (bp) {
BIO_free_all(bp);
bp = NULL;
}
EVP_cleanup();
return NULL;
}

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4433] Memory leak in X509_REQ_to_X509

[Ramunas Jurgilas via RT]

Hello OpenSSL Team,

During memory leak hunting on iOS platform I noticed, that function 
X509_REQ_to_X509 generates memory. Bellow you can found code snapshot.

As well I would like to know do you plan to fix this memory leak? If yes, then 
when?

Best regards,
Ramunas

X509_REQ *req = NULL;

EVP_PKEY *key = EVP_PKEY_new();
// Setup key ...

X509_REQ_set_pubkey(req,key);
X509_REQ_sign(req,key,EVP_sha256())
X509 *cert = X509_REQ_to_X509(req, 365, key); // Memory leak here!!!

// Free the memory.
-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4433
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4220] Simple BIO demo make memory leak

[Rich Salz via RT]

In 1.1 you don't need to do anything, openssl will free its internal resources.

before 1.1 you have to call various free/release routines to remove internal
state. see what is done in the apps, for example.

closing this ticket.

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4220
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Emilia Käsper via RT]

Yep, there is no need to clean up early here (we don't guarantee that errored
calls leave everything in a pristine unmodified state). Plus this does indeed
forget to zero the pointer. Closing. Thanks for submitting, though, and thanks
David for the review!

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[David Benjamin via RT]

By the way, returning the original subject, I don't believe there is a leak
here.

If EC_GROUP_copy fails, dest still exists and is owned by the caller. It's
the caller's obligation to call EC_GROUP_free and that will release the
partially-copied EC_GROUP. (Which will, with this patch, cause a
double-free because the unnecessarily freed pointers aren't nulled.)

David

On Wed, Mar 9, 2016 at 1:00 PM Bill Parker via RT  wrote:

> Geez,
>
> What did I start here (egad) :)
>
> Bill
>
> On Wed, Mar 9, 2016 at 5:03 AM, Salz, Rich via RT  wrote:
>
> > > No, you got that right, NULL being 'safe' to free varies with OS.
> >
> > Except we mandate ANSI C which means it's portable :)
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
> > Please log in as guest with password guest if prompted
> >
> >
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
> Please log in as guest with password guest if prompted
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Bill Parker via RT]

Geez,

What did I start here (egad) :)

Bill

On Wed, Mar 9, 2016 at 5:03 AM, Salz, Rich via RT  wrote:

> > No, you got that right, NULL being 'safe' to free varies with OS.
>
> Except we mandate ANSI C which means it's portable :)
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Salz, Rich via RT]

> No, you got that right, NULL being 'safe' to free varies with OS. 

Except we mandate ANSI C which means it's portable :)

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Richard Moore]

On 9 March 2016 at 05:30, Peter Waltenberg  wrote:

> No, you got that right, NULL being 'safe' to free varies with OS.
>
>
​It shouldn't if you're programming in C, from the standard (C89):

The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc , malloc , or realloc function, or if the
space has been deallocated by a call to free or realloc , the behavior is
undefined.

Cheers

Rich.​
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Richard Moore via RT]

On 9 March 2016 at 05:30, Peter Waltenberg  wrote:

> No, you got that right, NULL being 'safe' to free varies with OS.
>
>
​It shouldn't if you're programming in C, from the standard (C89):

The free function causes the space pointed to by ptr to be deallocated,
that is, made available for further allocation. If ptr is a null pointer,
no action occurs. Otherwise, if the argument does not match a pointer
earlier returned by the calloc , malloc , or realloc function, or if the
space has been deallocated by a call to free or realloc , the behavior is
undefined.

Cheers

Rich.​

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Peter Waltenberg via RT]

 No, you got that right, NULL being 'safe' to free varies with OS.

But - you aren't calling free() directly, THIS makes it safe. That's one of the
other benefits of having objects allocated and released by internal functions
rather than doing it directly.

void BN_MONT_CTX_free(BN_MONT_CTX *mont)
{
if (mont == NULL)
return;

BN_clear_free(&(mont->RR));
BN_clear_free(&(mont->N));
BN_clear_free(&(mont->Ni));
if (mont->flags & BN_FLG_MALLOCED)
OPENSSL_free(mont);
}


-"openssl-dev" <openssl-dev-boun...@openssl.org> wrote: -From: Bill
Parker via RT
Sent by: "openssl-dev"
Date: 03/09/2016 07:53AM
Cc: openssl-dev@openssl.org
Subject: Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory
leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

I must be brain dead today, since free'ing something that is already NULL
is not a problem (geez)...

Heh

On Tue, Mar 8, 2016 at 12:01 PM, Salz, Rich via RT <r...@openssl.org> wrote:

>
> > + if (dest->mont_data != NULL)
> > + BN_MONT_CTX_free(dest->mont_data);
>
> Free routines don't need to check for non-NULL.
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
> Please log in as guest with password guest if prompted
>
>

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Peter Waltenberg]

 No, you got that right, NULL being 'safe' to free varies with OS. But - you aren't calling free() directly, THIS makes it safe. That's one of the other benefits of having objects allocated and released by internal functions rather than doing it directly.void BN_MONT_CTX_free(BN_MONT_CTX *mont){    if (mont == NULL)    return;    BN_clear_free(&(mont->RR));    BN_clear_free(&(mont->N));    BN_clear_free(&(mont->Ni));    if (mont->flags & BN_FLG_MALLOCED)    OPENSSL_free(mont);}-"openssl-dev" <openssl-dev-boun...@openssl.org> wrote: -From: Bill Parker via RT <r...@openssl.org>Sent by: "openssl-dev" <openssl-dev-boun...@openssl.org>Date: 03/09/2016 07:53AMCc: openssl-dev@openssl.orgSubject: Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memoryleak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'I must be brain dead today, since free'ing something that is already NULLis not a problem (geez)...HehOn Tue, Mar 8, 2016 at 12:01 PM, Salz, Rich via RT <r...@openssl.org> wrote:>> > +               if (dest->mont_data != NULL)> > +                   BN_MONT_CTX_free(dest->mont_data);>> Free routines don't need to check for non-NULL.>>> --> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401> Please log in as guest with password guest if prompted>>-- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401Please log in as guest with password guest if prompted-- openssl-dev mailing listTo unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Bill Parker via RT]

I must be brain dead today, since free'ing something that is already NULL
is not a problem (geez)...

Heh

On Tue, Mar 8, 2016 at 12:01 PM, Salz, Rich via RT  wrote:

>
> > +   if (dest->mont_data != NULL)
> > +   BN_MONT_CTX_free(dest->mont_data);
>
> Free routines don't need to check for non-NULL.
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Salz, Rich]

> >> +   if (dest->mont_data != NULL)
> >> +   BN_MONT_CTX_free(dest->mont_data);
> >
> >Free routines don't need to check for non-NULL.
> 
> Yes, don’t *have* to. But does it hurt to check?

It makes folks wonder why the check is only there sometimes.  It adds to code  
complexity/test-coverage issues.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Blumenthal, Uri - 0553 - MITLL]

On 3/8/16, 15:01 , "openssl-dev on behalf of Salz, Rich via RT"
 wrote:

>
>> +   if (dest->mont_data != NULL)
>> +   BN_MONT_CTX_free(dest->mont_data);
>
>Free routines don't need to check for non-NULL.

Yes, don’t *have* to. But does it hurt to check?


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Salz, Rich via RT]

> +   if (dest->mont_data != NULL)
> +   BN_MONT_CTX_free(dest->mont_data);

Free routines don't need to check for non-NULL.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4401] [PATCH] plug potential memory leak(s) in OpenSSL 1.1 pre 4 in 'ec_lib.c'

[Bill Parker via RT]

Hello All,

In reviewing code in directory 'crypto/ec', file 'ec_lib.c'', there
appears to be allocated memory which is not released when a return 0;
is encountered in some cases of OPENSSL_malloc().  The patch file below
should address/correct these minor leaks:

--- ec_lib.c.orig   2016-03-08 10:46:45.885643748 -0800
+++ ec_lib.c2016-03-08 10:53:51.196698596 -0800
@@ -231,8 +231,11 @@
 if (src->generator != NULL) {
 if (dest->generator == NULL) {
 dest->generator = EC_POINT_new(dest);
-if (dest->generator == NULL)
+if (dest->generator == NULL) {
+   if (dest->mont_data != NULL)
+   BN_MONT_CTX_free(dest->mont_data);
 return 0;
+   }
 }
 if (!EC_POINT_copy(dest->generator, src->generator))
 return 0;
@@ -256,7 +259,11 @@
 if (src->seed) {
 OPENSSL_free(dest->seed);
 dest->seed = OPENSSL_malloc(src->seed_len);
-if (dest->seed == NULL)
+if (dest->seed == NULL) {
+   if (dest->mont_data != NULL)
+   EC_POINT_clear_free(dest->mont_data);
+   if (dest->generator != NULL)
+   EC_POINT_clear_free(dest->generator);
 return 0;
 if (!memcpy(dest->seed, src->seed, src->seed_len))
 return 0;

===

Bill Parker (wp02855 at gmail dot com)

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4401
Please log in as guest with password guest if prompted



ec_lib.c.patch
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4400] [PATCH] plug potential memory leak in OpenSSL 1.1 pre 4

[Bill Parker via RT]

Hello All,

In reviewing source code in directory 'crypto/ocsp', file 'ocsp_ht.c',
there is a minor flaw in the test logic which could allow a small memory
leak to develop.  The patch file below should address/correct this issue:

--- ocsp_ht.c.orig  2016-03-08 10:24:51.821632969 -0800
+++ ocsp_ht.c   2016-03-08 10:26:32.062373052 -0800
@@ -119,13 +119,18 @@
 rctx->state = OHS_ERROR;
 rctx->max_resp_len = OCSP_MAX_RESP_LENGTH;
 rctx->mem = BIO_new(BIO_s_mem());
+if (rctx->mem == NULL)
+   OCSP_REQ_CTX_free(rctx);
+   return NULL;
+}
 rctx->io = io;
 if (maxline > 0)
 rctx->iobuflen = maxline;
 else
 rctx->iobuflen = OCSP_MAX_LINE_LEN;
 rctx->iobuf = OPENSSL_malloc(rctx->iobuflen);
-if (rctx->iobuf == NULL || rctx->mem == NULL) {
+if (rctx->iobuf == NULL) {
+   OCSP_REQ_CTX_free(rctx->mem);
 OCSP_REQ_CTX_free(rctx);
 return NULL;
 }

===

Bill Parker (wp02855 at gmail dot com)

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4400
Please log in as guest with password guest if prompted



ocsp_ht.c.patch
Description: Binary data
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2439] bug report: memory leak

[Rich Salz via RT]

In our review, the code is correct and there is no leak. Please provide a patch
against the current release if you think otherwise.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-
http://rt.openssl.org/Ticket/Display.html?id=2439

Please log in as guest with password guest if prompted

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2536] Memory leak in d2i_RSA_PUBKEY() (concise test code included)

[Rich Salz via RT]

The d2i routines move the pointer to the next thing. So you have do save key,
pass in a copy, and then delete the original key.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org


-
http://rt.openssl.org/Ticket/Display.html?id=2536

Please log in as guest with password guest if prompted

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2673] Bug report: OpenSSL Memory leak in B64 encode

[Rich Salz via RT]

An OpenSSL cleanup call (such as clean_ex_data) must be called before existing,
else internal data will be kept around.

Closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak

[Rich Salz via RT]

No reply, cannot reproduce the bug, closing the ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1802] Bug report: Persistent memory leak that cannot be freed

[Rich Salz via RT]

This is reported against 0.9.8; please open a new ticket if still a problem
with current releases.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] "openssl s_client" memory leak

[Salz, Rich]

Thanks for looking into this.
I don't think it's gonna be on anyone's high priority list to fix in the next 
release, so feel free to keep at it :)

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4259] Bug: Apparent memory leak in kssl.c

[Highland, Glenn via RT]

Hello -

I ran OpenSSL v1.0.2e through static analysis (Cppcheck v1.62) and there was 
one apparent memory leak identified as follows:

openssl-1.0.2e\ssl\kssl.c   error   line: 2234   Memory leak: p_data (new_p is 
freed in the error return condition, but its data field references a buffer 
addressed by p_data and that is not freed first)

This is not impacting our use of OpenSSL.  It was found during a preparatory 
step to porting v1.0.2e in the near future.

Glenn Highland
Lead Software Engineer

Digi International(c) Wireless Design Services Inc.
11001 Bren Road East, Minnetonka, MN 55343

Direct:   612-524-7153
Main: 612-435-0789
Email: glenn.highl...@digi.com<mailto:glenn.highl...@digi.com>

http://www.digi.com/wireless-design-services/

"Exite de medio eorum et separamini."


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] "openssl s_client" memory leak

[Gisle Vanem]

There seems to be some memory leak(s) somewhere during the life
of 's_client_main()'. Example from a client.bat here:

  set OPENSSL_DEBUG_MEMORY=on
  echo -e GET /ssltest/viewMyClient.html\r\n | openssl.exe s_client ^
 -connect www.ssllabs.com:443

('echo -e' is from Cygwin32).

All .html output gets produced correctly; ends with:
  read:errno=0
and dumped okay in Lynx.

But the mem-tracker reports:
  [12:06:07]  6930 file=crypto/bio/bio_lib.c, line=68, thread=1092, number=72, 
address=0x284ef78
  72 bytes leaked in 1 chunks

And adding other options show additional leaks.
E.g. '-nbio_test -reconnect' results in 12 leaks:

  [12:15:17] 13704 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf468
  [12:15:15] 13016 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccedb0
  [12:15:18] 14345 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf238
  [12:15:14]  6906 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2c7e618
  [12:15:17] 13705 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf2a8
  [12:15:15] 13017 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccee20
  [12:15:16] 13363 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf078
  [12:15:14]  6907 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2c7e688
  [12:15:18] 14344 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf0e8
  [12:15:17] 14022 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2cceeb8
  [12:15:16] 13364 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccef28
  [12:15:17] 14021 file=crypto/bio/bio_lib.c, line=68, thread=4248, number=72, 
address=0x2ccf628
  864 bytes leaked in 12 chunks

line 68 in bio_lib.c is inside BIO_new() which gives me no clue as to
the caller(s). And these order-values in column 2, what exactly are they?

All this is with a ver 0x1013L, MingW + gcc 5.1 build on Win-10.
Maybe someone can verify this happening on other OSes too?

BTW. 'memleaktest.exe freeit' reports nothing. So the mem-dbg seems okay
in this memtleaktest program. But maybe not in the 'big-picture'?

-- 
--gv
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4220] Simple BIO demo make memory leak

[wangjin via RT]

 

Dear,

 

Recently, I got an issue on my RHEL6.5 x64 platform with original
openssl-1.0.2e  without patch.  Please find the attached files for testing
demo, this simple demo will generate Memory Leak, is it a bug ? I am not
sure why?  Thank you for in advance.

 

The same test on Win7 x64, VS2008, appear again.

 

Best Regards,

  _  

Jin Linux


#include 
#include 
#include 

#include "openssl/bio.h"

int main(int argc, char* argv[])
{
BIO* b = NULL;

b = BIO_new(BIO_s_mem());
/* here is not free totally.
 * I strace and found that, BIO_free() is not 
 * free the inner lhash and stack structure.
 */
BIO_free_all(b);
//  or BIO_free();

return 0;
}
>>>>GCC version
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.7 20120313 (Red Hat 4.4.7-11) (GCC) 


>>> uname -a
Linux localhost.localdomain 2.6.32-431.el6.x86_64 #1 SMP Sun Nov 10 22:19:54 
EST 2013 x86_64 x86_64 x86_64 GNU/Linux


>>> valgrind ./bio_mem
==14689== Memcheck, a memory error detector
==14689== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==14689== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==14689== Command: ./bio_mem
==14689== 
==14689== Conditional jump or move depends on uninitialised value(s)
==14689==at 0x355F417FE6: index (strchr.S:55)
==14689==by 0x355F4075A2: expand_dynamic_string_token (dl-load.c:425)
==14689==by 0x355F4079DD: _dl_map_object (dl-load.c:2301)
==14689==by 0x355F40196D: map_doit (rtld.c:626)
==14689==by 0x355F40E7B5: _dl_catch_error (dl-error.c:177)
==14689==by 0x355F401886: do_preload (rtld.c:815)
==14689==by 0x355F403A8C: dl_main (rtld.c:1629)
==14689==by 0x355F415AA5: _dl_sysdep_start (dl-sysdep.c:249)
==14689==by 0x355F401412: _dl_start (rtld.c:331)
==14689==by 0x355F400AE7: ??? (in /lib64/ld-2.18.so)
==14689== 
==14689== Conditional jump or move depends on uninitialised value(s)
==14689==at 0x355F417FEB: index (strchr.S:58)
==14689==by 0x355F4075A2: expand_dynamic_string_token (dl-load.c:425)
==14689==by 0x355F4079DD: _dl_map_object (dl-load.c:2301)
==14689==by 0x355F40196D: map_doit (rtld.c:626)
==14689==by 0x355F40E7B5: _dl_catch_error (dl-error.c:177)
==14689==by 0x355F401886: do_preload (rtld.c:815)
==14689==by 0x355F403A8C: dl_main (rtld.c:1629)
==14689==by 0x355F415AA5: _dl_sysdep_start (dl-sysdep.c:249)
==14689==by 0x355F401412: _dl_start (rtld.c:331)
==14689==by 0x355F400AE7: ??? (in /lib64/ld-2.18.so)
==14689== 
==14689== 
==14689== HEAP SUMMARY:
==14689== in use at exit: 416 bytes in 6 blocks
==14689==   total heap usage: 8 allocs, 2 frees, 552 bytes allocated
==14689== 
==14689== LEAK SUMMARY:
==14689==definitely lost: 0 bytes in 0 blocks
==14689==indirectly lost: 0 bytes in 0 blocks
==14689==  possibly lost: 0 bytes in 0 blocks
==14689==still reachable: 416 bytes in 6 blocks
==14689== suppressed: 0 bytes in 0 blocks
==14689== Rerun with --leak-check=full to see details of leaked memory
==14689== 
==14689== For counts of detected and suppressed errors, rerun with: -v
==14689== Use --track-origins=yes to see where uninitialised values come from
==14689== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

[Matt Caswell via RT]

On Tue Dec 22 17:02:07 2015, tsh...@akamai.com wrote:
> Hello OpenSSL org:
>
> I found the following issue via code inspection. In
> tls_process_client_key_exchange(), when EC is disabled, and an error
> occurs in ssl_generate_master_secret() or RAND_bytes(), the error path
> does not free rsa_decrypt.


Patch applied. Many thanks.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4184] Memory leak in DSA redo case

[Kurt Roeckx via RT]

Fixed.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4197] [PATCH] Memory leak in state machine in error path

[Short, Todd via RT]

Hello OpenSSL org:

I found the following issue via code inspection. In 
tls_process_client_key_exchange(), when EC is disabled, and an error occurs in 
ssl_generate_master_secret() or RAND_bytes(), the error path does not free 
rsa_decrypt.

Note that rsa_decrypt is not conditionally defined by OPENSSL_NO_RSA, so I did 
not wrap the free with that conditional.
--
-Todd Short
// tsh...@akamai.com<mailto:tsh...@akamai.com>
// "One if by land, two if by sea, three if by the Internet."



0001-Memory-leak-in-state-machine-in-error-path.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] memory leak?

[Wall, Stephen]

This looks like a potential memory leak to me...

openssl-1.0.2e/crypto/x509/x509_lu.c:

X509_STORE *X509_STORE_new(void)
{
X509_STORE *ret;

if ((ret = (X509_STORE *)OPENSSL_malloc(sizeof(X509_STORE))) == NULL)
return NULL;
ret->objs = sk_X509_OBJECT_new(x509_object_cmp);
ret->cache = 1;
ret->get_cert_methods = sk_X509_LOOKUP_new_null();
ret->verify = 0;
ret->verify_cb = 0;

if ((ret->param = X509_VERIFY_PARAM_new()) == NULL)
return NULL;


If X509_VERIFY_PARAM_new() fails, function returns NULL without freeing ret.


- spw
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4184] Memory leak in DSA redo case

[David Benjamin via RT]

dsa_do_sign retries the operation if |r| or |s| end up zero. This results
in leaking the first iteration's value of |ret| since you end up clobbering
the previous allocation.
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/dsa/dsa_ossl.c;h=34b4a4ea4a267b62b21916a85ab79350cd276065;hb=HEAD#l135

The fix is to switch the order of the check and allocating |ret|:
See
https://boringssl.googlesource.com/boringssl/+/2936170d68ec617e1e6f0c2def86728ba29312b7%5E%21/#F0

(This was found via clang's scan-build tool.)

David

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE

[Stephen Henson via RT]

Assigned CVE-2015-3195 and fixed now. Thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Openssl Memory Leak

[Salz, Rich]

Ø  Can anyone let us know about the leaks and will SSL_FREE() will free the 
above memory.

It should.  Try it.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4131] AutoReply: Memory leak when parsing invalid X509_ATTRIBUTE

[Adam Langley via RT]

(Please note that credit for this goes to libFuzzer.)


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key()

[Григорий Загон via RT]

Hello!

I work with openssl 1.0.2d, and I found a memory leak in
STORE_store_private_key() function (defined in crypto/store/str_lib.c).
Here is a code fragment:

465:int STORE_store_private_key(STORE *s, EVP_PKEY *data,
466:OPENSSL_ITEM attributes[],
467:OPENSSL_ITEM parameters[])
468:{
469:STORE_OBJECT *object;
470:int i;
471:
472:check_store(s, STORE_F_STORE_STORE_PRIVATE_KEY,
473:store_object, STORE_R_NO_STORE_OBJECT_FUNCTION);
474:
475:object = STORE_OBJECT_new();
476:if (!object) {
477:STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE);
478:return 0;
479:}
480:object->data.key = EVP_PKEY_new();
481:if (!object->data.key) {
482:STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE);
483:return 0;
484:}
485:
486:CRYPTO_add(>references, 1, CRYPTO_LOCK_EVP_PKEY);
487:#ifdef REF_PRINT
488:REF_PRINT("EVP_PKEY", data);
489:#endif
490:object->data.key = data;

At line 480 pointer to newly allocated key object is stored in
'object->data.key' variable.
At line 490 variable 'object->data.key' is overwritten with new value. So,
memory allocated at line 480 will never be freed.

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4134] [BUG] Memory leak in STORE_store_private_key()

[Richard Levitte via RT]

STORE is an experimental API that isn't used in 1.0.2 (or any earlier series).
For the next major version, the STORE API is being entirely rewritten. Please
stay tuned.

In the mean time, I'll simply close this ticket,

Vid Ons, 11 Nov 2015 kl. 04.15.16, skrev gzago...@gmail.com:
> Hello!
>
> I work with openssl 1.0.2d, and I found a memory leak in
> STORE_store_private_key() function (defined in crypto/store/str_lib.c).
> Here is a code fragment:
>
> 465:int STORE_store_private_key(STORE *s, EVP_PKEY *data,
> 466: OPENSSL_ITEM attributes[],
> 467: OPENSSL_ITEM parameters[])
> 468:{
> 469: STORE_OBJECT *object;
> 470: int i;
> 471:
> 472: check_store(s, STORE_F_STORE_STORE_PRIVATE_KEY,
> 473: store_object, STORE_R_NO_STORE_OBJECT_FUNCTION);
> 474:
> 475: object = STORE_OBJECT_new();
> 476: if (!object) {
> 477: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE);
> 478: return 0;
> 479: }
> 480: object->data.key = EVP_PKEY_new();
> 481: if (!object->data.key) {
> 482: STOREerr(STORE_F_STORE_STORE_PRIVATE_KEY, ERR_R_MALLOC_FAILURE);
> 483: return 0;
> 484: }
> 485:
> 486: CRYPTO_add(>references, 1, CRYPTO_LOCK_EVP_PKEY);
> 487:#ifdef REF_PRINT
> 488: REF_PRINT("EVP_PKEY", data);
> 489:#endif
> 490: object->data.key = data;
>
> At line 480 pointer to newly allocated key object is stored in
> 'object->data.key' variable.
> At line 490 variable 'object->data.key' is overwritten with new value. So,
> memory allocated at line 480 will never be freed.


--
Richard Levitte
levi...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4131] Memory leak when parsing invalid X509_ATTRIBUTE

[Adam Langley via RT]

The following code:

EVP_PKEY_free(d2i_AutoPrivateKey(NULL, , n));

Will leak memory when fed this input:

30390201023009060138080469303080301901029ff88b298030b01b060922be0804e930864886f70d3a0180093080060102308030013b020420308204e930c3e8300105308030013b01040202ff003029021103292902009930800621022404e83001010430801b06092a86483001aa0286c030dfe980

I believe this is because the X509_ATTRIBUTE item "combines" the first
and second members. Thus, after parsing an ASN1_OBJECT, the main loop
in ASN1_item_ex_d2i does `pseqval = asn1_get_field_ptr(pval, seqtt);`
with i=1 and gets pseqval=pval. ASN1_item_ex_d2i has code to "/* Free
up and zero CHOICE value if initialised */", but it doesn't trigger in
this situation and then ASN1_item_ex_d2i overwrites the ASN1_OBJECT
pointer and leaks it.

The trace of the leak is the following, from 1.0.1 HEAD:

==12959== 41 (40 direct, 1 indirect) bytes in 1 blocks are definitely
lost in loss record 7 of 16
==12959==at 0x40307C4: malloc
(valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270)
==12959==by 0x40AB43: default_malloc_ex (/agl/openssl/crypto/mem.c:79)
==12959==by 0x40B1D3: CRYPTO_malloc (/agl/openssl/crypto/mem.c:342)
==12959==by 0x432006: ASN1_OBJECT_new
(/agl/openssl/crypto/asn1/a_object.c:346)
==12959==by 0x431E6E: c2i_ASN1_OBJECT
(/agl/openssl/crypto/asn1/a_object.c:301)
==12959==by 0x4069D7: asn1_ex_c2i (/agl/openssl/crypto/asn1/tasn_dec.c:874)
==12959==by 0x40682A: asn1_d2i_ex_primitive
(/agl/openssl/crypto/asn1/tasn_dec.c:831)
==12959==by 0x404F15: ASN1_item_ex_d2i
(/agl/openssl/crypto/asn1/tasn_dec.c:207)
==12959==by 0x40632C: asn1_template_noexp_d2i
(/agl/openssl/crypto/asn1/tasn_dec.c:691)
==12959==by 0x405F20: asn1_template_ex_d2i
(/agl/openssl/crypto/asn1/tasn_dec.c:579)
==12959==by 0x4059DD: ASN1_item_ex_d2i
(/agl/openssl/crypto/asn1/tasn_dec.c:443)
==12959==by 0x4061B6: asn1_template_noexp_d2i
(/agl/openssl/crypto/asn1/tasn_dec.c:663)

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Openssl Memory Leak

[T@Run..............! Polisetty]

Hai All,

We are hitting at critical Memory leaks in ssl3_get_client_certificate()
 where are not able to run calls in load. The backtrace of the leak is

 291 bytes in 97 blocks are indirectly lost in loss record 2,354 of 3,052
==31717==at 0x4C28BED: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31717==by 0x516C4FE: default_malloc_ex (mem.c:79)
==31717==by 0x516CBD5: CRYPTO_malloc (mem.c:342)
==31717==by 0x5228977: c2i_ASN1_OBJECT (a_object.c:315)
==31717==by 0x523B86B: asn1_ex_c2i (tasn_dec.c:874)
==31717==by 0x523B6BE: asn1_d2i_ex_primitive (tasn_dec.c:831)
==31717==by 0x5239DBD: ASN1_item_ex_d2i (tasn_dec.c:207)
==31717==by 0x523B187: asn1_template_noexp_d2i (tasn_dec.c:691)
==31717==by 0x523AD6D: asn1_template_ex_d2i (tasn_dec.c:579)
==31717==by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443)
==31717==by 0x523B009: asn1_template_noexp_d2i (tasn_dec.c:663)
==31717==by 0x523AC7C: asn1_template_ex_d2i (tasn_dec.c:555)
==31717==by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443)
==31717==by 0x523B187: asn1_template_noexp_d2i (tasn_dec.c:691)
==31717==by 0x523AD6D: asn1_template_ex_d2i (tasn_dec.c:579)
==31717==by 0x523A815: ASN1_item_ex_d2i (tasn_dec.c:443)
==31717==by 0x5239BAE: ASN1_item_d2i (tasn_dec.c:146)
==31717==by 0x5232A80: d2i_X509 (x_x509.c:154)
==31717==by 0x4E54775: ssl3_get_client_certificate (s3_srvr.c:3174)
==31717==by 0x4E72D2E: dtls1_accept (d1_srvr.c:605)
==31717==by 0x4E7A0DC: dtls1_read_bytes (d1_pkt.c:811)
==31717==by 0x4E5F47C: ssl3_read_internal (s3_lib.c:4246)
==31717==by 0x4E5F52B: ssl3_read (s3_lib.c:4270)
==31717==by 0x4E81F87: SSL_read (ssl_lib.c:1021)


Can anyone let us know about the leaks and will SSL_FREE() will free the
above memory.

 Please help .

Regards
Satya
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

[Srinivas Thota via RT]

Please ignore this.

Issue found in user code.

Thank you so much.


On Thu, Oct 22, 2015 at 12:18 AM, Salz, Rich via RT  wrote:

> > I am trying figure out valgrind report leak. in openssl 1.0.1c.
>
> You don't have enough of the backtrace for us to reproduce it.  Please add
> a simple demo program.
>
>

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

[Rich Salz via RT]

closing per request of submittor.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

[Srinivas Thota via RT]

Hi,

I am trying figure out valgrind report leak. in openssl 1.0.1c.

Can any one comment if this already fixed and what is the fix.

==30824== 912 (56 direct, 856 indirect) bytes in 1 blocks are definitely
lost in loss record 837 of 907
==30824==at 0x4A07F9E: malloc (vg_replace_malloc.c:291)
==30824==by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0)
==30824==by 0x36136FA2D9: EVP_PKEY_new (in /lib64/libcrypto.so.1.0.0)
==30824==by 0x3613708EC7: X509_PUBKEY_get (in /lib64/libcrypto.so.1.0.0)
==30824==by 0x3613724B41: X509_get_pubkey_parameters (in
/lib64/libcrypto.so.1.0.0)
==30824==by 0x36137253D3: X509_verify_cert (in
/lib64/libcrypto.so.1.0.0)

Thanks,
Srinivas

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get

[Salz, Rich via RT]

> I am trying figure out valgrind report leak. in openssl 1.0.1c.

You don't have enough of the backtrace for us to reproduce it.  Please add a 
simple demo program.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4092] Fwd: Memory Leak in X509_STORE_CTX_init

[Srinivas Thota via RT]

Hi,

Valgrind Reported Leak

=
==16773== 56 bytes in 1 blocks are definitely lost in loss record 806 of
1,182
==16773==at 0x4A07F9E: malloc (vg_replace_malloc.c:291)
==16773==by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0)
==16773==by 0x361372B5F6: X509_VERIFY_PARAM_new (in
/lib64/libcrypto.so.1.0.0)
==16773==by 0x3613725AAA: X509_STORE_CTX_init (in
/lib64/libcrypto.so.1.0.0)

=

Code


void X509_STORE_CTX_cleanup(X509_STORE_CTX *ctx)
{
if (ctx->cleanup)
ctx->cleanup(ctx);
if (ctx->param != NULL) {
if (ctx->parent == NULL) // ONLY if parent is NULL param is free'd.
X509_VERIFY_PARAM_free(ctx->param);
ctx->param = NULL;
}
...
}
=

Code checks for ctx->parent and only then it is freeing ctx->param.


This has to be corrected to free ctx->param even if ctx->parent is NULL.


Please let me know if this is correct fix.

Thanks,

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4031] memory leak in crypto/asn1/x_x509a.c

[Rich Salz via RT]

create by mistake.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c

[Rich Salz via RT]

yes, it looks like these have been fixed.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #1543] memory leak in crypto/asn1/x_x509a.c

[Alessandro Ghedini via RT]

Same as #1542, the patch is mangled but I think everything is already fixed so
this can be closed.

Cheers


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c

[Alessandro Ghedini via RT]

On Sat, Sep 05, 2015 at 01:49:52pm +, Alessandro Ghedini via RT wrote:
> Same as #1542, the patch is mangled but I think everything is already fixed so
> this can be closed.

Same as #4031. It was supposed to be a reply to #1543 and can be closed.

Cheers


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4031] Re: [openssl-dev #1543] memory leak in crypto/asn1/x_x509a.c

[Alessandro Ghedini via RT]

Same as #1542, the patch is mangled but I think everything is already fixed so
this can be closed.

Cheers

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3917] Bug report -- potential memory leak

[Rich Salz via RT]

OpenSSL_1_0_2-stable 4475451 RT3917: add cleanup on an error path
master 7fba840 RT3917: add cleanup on an error path

Author: Rich Salz rs...@akamai.com
Date: Sun Jun 21 15:37:53 2015 -0400

RT3917: add cleanup on an error path

Reviewed-by: Richard Levitte levi...@openssl.org

--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3917] Bug report -- potential memory leak

[Martin Vejnár via RT]

Hi,

affects all systems, happens at least in OpenSSL 1.0.2c.

In `crypto/cms/cms_smime.c`, the function `CMS_verify` will leak memory pointed 
to by `cms_certs` and `crls` variables if the call to `BIO_new_mem_buf` on line 
374 fails.

Thanks,
--
Martin


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods()

[Rich Salz via RT]

Thanks! Applied.
commit 45d051c82563a75b07ec54b63e3a5bbad388ab67
Author: Gunnar Kudrjavets gunna...@exchange.microsoft.com
Date: Wed May 13 15:13:55 2015 -0400

RT3848: Call SSL_COMP_free_compression_methods

Signed-off-by: Rich Salz rs...@akamai.com
Reviewed-by: Matt Caswell m...@openssl.org
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req

[Hanno Boeck via RT]

The code in apps/req.c will use the variable out for both the key and
the csr outfile.

This causes a memory leak because if both a private key and a csr is
written the variable is re-used without freeing it.

See attached patch. (This could also be fixed by using a different var
for both files, could be considered more consistent, but I decided to
use a less invasive patch that just needs to add a single line.)

Please apply patch.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

--- a/apps/req.c	2015-05-25 14:54:22.131858356 +0200
+++ b/apps/req.c	2015-05-25 15:15:01.999814984 +0200
@@ -612,6 +612,7 @@
 }
 goto end;
 }
+BIO_free(out);
 BIO_printf(bio_err, -\n);
 }
 


pgpRoQkvMoFB_.pgp
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req

[Rich Salz via RT]

commit cf89a80e25b79ae0e6004e4a2509bf656fb59168
Author: Hanno BC3B6ck ha...@hboeck.de
Date: Mon May 25 16:18:07 2015 -0400

RT3861: Mem/bio leak in req command

The out variable is used for both key and csr. Close it after
writing the first one so it can be re-used when writing the other.

Signed-off-by: Rich Salz rs...@openssl.org
Reviewed-by: Tim Hudson t...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods()

[Gunnar Kudrjavets via RT]

Hello,

Currently 'apps_shutdown()' in 'openssl.c' isn't freeing the compression
methods. This is causing the CRT debug heap (and I assume various other
tools) to indicate a memory leak. Though OS will free all the resources
when user-mode application exits, it's better to do this explicitly inside
'apps_shutdown()'. As a bonus this change also helps to reach the clean
state where debug heap is happy :-)

Thank you,
Gunnar Kudrjavets


From 108f2ef97d866d3750aac0dbe91cffe68e8b5181 Mon Sep 17 00:00:00 2001
From: Gunnar Kudrjavets gunna...@microsoft.com
Date: Wed, 13 May 2015 09:25:02 -0700
Subject: [PATCH] Fix memory leak caused by not calling
 SSL_COMP_free_compression_methods()

Currently 'apps_shutdown()' in 'openssl.c' isn't freeing the compression
methods. This is causing the CRT debug heap (and I assume various other
tools) to indicate a memory leak. Though OS will free all the resources
when user-mode application exits, it's better to do this explicitly inside
'apps_shutdown()'. As a bonus this change also helps to reach the clean
state where debug heap is happy :-)

CRT debug heap indicating that there's a leak:

Detected memory leaks!
Dumping objects -
{3375} normal block at 0x0AE76FE8, 16 bytes long.
 Data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
{3374} normal block at 0x079A2FE8, 20 bytes long.
 Data:  o   00 00 00 00 E8 6F E7 0A 00 00 00 00 04 00 00 00
Object dump complete.

Stack trace pointing to the allocation which causes the leak:

0:000 |
.  0id: 84c create  name: openssl.exe
0:000 kcn
 #
00 MSVCR120D!_heap_alloc_dbg_impl
01 MSVCR120D!_nh_malloc_dbg_impl
02 MSVCR120D!_nh_malloc_dbg
03 MSVCR120D!malloc
04 LIBEAY32!default_malloc_ex
05 LIBEAY32!CRYPTO_malloc
06 LIBEAY32!sk_new
07 SSLEAY32!load_builtin_compressions
08 SSLEAY32!SSL_COMP_get_compression_methods
09 SSLEAY32!SSL_library_init
0a openssl!apps_startup
0b openssl!main
0c openssl!__tmainCRTStartup
0d openssl!mainCRTStartup
0e KERNEL32!BaseThreadInitThunk
0f ntdll!__RtlUserThreadStart
10 ntdll!_RtlUserThreadStart
---
 apps/openssl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/apps/openssl.c b/apps/openssl.c
index fa3b683..952eaa4 100644
--- a/apps/openssl.c
+++ b/apps/openssl.c
@@ -188,6 +188,7 @@ static void apps_shutdown()
 CONF_modules_unload(1);
 #ifndef OPENSSL_NO_COMP
 COMP_zlib_cleanup();
+SSL_COMP_free_compression_methods();
 #endif
 OBJ_cleanup();
 EVP_cleanup();
-- 
1.9.5.msysgit.1

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions

[Rich Salz via RT]

fixed by steve H. See also ticket 1207, which will be closed when we update the
docs.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1714] DTLS: Memory leak when server receives close alert from unknown peer

[Matt Caswell via RT]

This was fixed some while ago. Closing ticket.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3662] [bug report]DTLS memory leak in dtls1_accept when use PSK in opensll 1.0.1j

[Matt Caswell via RT]

Please see:
https://www.openssl.org/support/faq.html#PROG13

Also see RT ticket 3824.

Closing this ticket as 3824 seems the better place to track this issue.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions

[Stephen Henson via RT]

On Wed Apr 29 00:34:11 2015, noloa...@gmail.com wrote:
 Is there any progress on this?


See SSL_COMP_free_compression_methods().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #2561] Re: Memory leak with SSL built-in compressions

[noloa...@gmail.com via RT]

Is there any progress on this?

Its been about 5 years, and folks are still having trouble with it. For example:

 * 
http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl.
 * 
http://openssl.6102.n7.nabble.com/Preferred-way-to-free-ssl-comp-methods-td48573.html
 * 
http://openssl.6102.n7.nabble.com/Small-memory-leak-on-multithreaded-server-td54921.html

I know some others disagree, but that's really just bike shedding
(http://bikeshed.com/).If one person feels its OK to leak memory, then
that's fine. But everyone else should not be made to suffer the
other's consequences.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message

[Matt Caswell via RT]

Off list discussions have identified that this issue was due to user code
incorrectly re-calling DTLSv1_listen after it has already successfully
returned. Therefore closing this issue.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak

[Rich Salz via RT]

On Tue Dec 23 09:14:09 2014, luis.gar...@csr.com wrote:
 When using PKCS7_decrypt with the following parameters:

 BIO *bio = BIO_new(BIOS_s_mem());

 PKCS7 pointer, EVP_PKEY pointer, X509 pointer, bio, 0.

 I am getting a memory leak of 568 bytes.

Can you post a sample program? Or perhaps some kind of diagnostic that shows
WHERE the leak is occuring? (e.g,. valgrind on linux). Right now there's not
enough information to reproduce or analyze the problem.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3679] Memory leak in ssl_cert_dup (ssl/ssl_cert.c)

[David Ramos via RT]

Hello,

Our UC-KLEE tool found a memory leak in ssl_cert_dup (ssl/ssl_cert.c). The bug 
affects commit 43257b9f51de749262258668c77c2f0f99d7a15b from the 1.0.2 branch, 
but it appears to date back many years.

On line 222 of ssl/ssl_cert.c, ssl_cert_dup() allocates a new CERT:

ret = (CERT *)OPENSSL_malloc(sizeof(CERT));

If any of the subsequent allocations or _dup()’s fail, we jump to ‘err’, which 
frees many of the fields within ‘ret’, but forgets to free ‘ret’ itself 
(leaking 728 bytes on my x86_64 Linux build). I believe there needs to be a 
call to:

OPENSSL_free(ret);

before the 'return NULL' at line 440.

Please let me know if you have any questions.

Thanks,
-David



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1353] memory leak in EVP sign and verification functions

[Rich Salz via RT]

demo was probably7 fixed with these commits:
commit 89f534e1d30ed40a03455b36cda7da13734e7238
Author: Dr. Stephen Henson st...@openssl.org
Date: Fri Sep 28 00:47:36 2001 +

Make (ancient) sign.c demo compile again.

commit 5f6d0ea21050fd8a801c6681002e76689a5993b6
Author: Dr. Stephen Henson st...@openssl.org
Date: Wed Jun 9 23:33:48 1999 +

Reformat and modernise the sign.c demo.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #1353] memory leak in EVP sign and verification functions

[Rich Salz via RT]

demo was probably7 fixed with these commits:
commit 89f534e1d30ed40a03455b36cda7da13734e7238
Author: Dr. Stephen Henson st...@openssl.org
Date: Fri Sep 28 00:47:36 2001 +

Make (ancient) sign.c demo compile again.

commit 5f6d0ea21050fd8a801c6681002e76689a5993b6
Author: Dr. Stephen Henson st...@openssl.org
Date: Wed Jun 9 23:33:48 1999 +

Reformat and modernise the sign.c demo.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Huzaifa Sidhpurwala via RT]

This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:

Consider sv_body() in server.c

2237 con=SSL_new(ctx);

Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via

 295 s-kssl_ctx = kssl_ctx_new();

So SSL_new basically also allocates memory for con-kssl

Later in sv_body() at line 2252:

2252   if ((kctx = kssl_ctx_new()) != NULL)
2253 {
2254 SSL_set0_kssl_ctx(con, kctx);

This causes con-kssl_ctx to be rewritten by kctx, in doing so 56 bytes of
previously allocated memory is lost
and hence the memory leak for each connection made.


On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:

 Here is how to test it:

 openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
 -subj \
 /CN=localhost -nodes -batch -sha256

 valgrind --leak-check=full openssl s_server -key localhost.key -cert \
 localhost.crt -accept 4433

 ./poc.py

 Every run of poc.py causes 56 byte memory leak:

 ==11278== HEAP SUMMARY:
 ==11278== in use at exit: 910,716 bytes in 20,383 blocks
 ==11278==   total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
 allocated
 ==11278==
 ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of
 823
 ==11278==at 0x4C2745D: malloc (in
 /usr/lib64/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
 ==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
 ==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
 ==11278==by 0x436387: sv_body (s_server.c:2004)
 ==11278==by 0x44AC30: do_server (s_socket.c:324)
 ==11278==by 0x439C36: s_server_main (s_server.c:1901)
 ==11278==by 0x419377: do_cmd (openssl.c:489)
 ==11278==by 0x41906D: main (openssl.c:381)
 ==11278==
 ==11278== LEAK SUMMARY:
 ==11278==definitely lost: 56 bytes in 1 blocks
 ==11278==indirectly lost: 0 bytes in 0 blocks
 ==11278==  possibly lost: 0 bytes in 0 blocks
 ==11278==still reachable: 910,660 bytes in 20,382 blocks
 ==11278== suppressed: 0 bytes in 0 blocks
 ==11278== Reachable blocks (those to which a pointer was found) are not
 shown.
 ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
 ==11278==
 ==11278== For counts of detected and suppressed errors, rerun with: -v
 ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
 


 Acknowledgement Text Required: Yes
 Community Trackers Required  : Yes
 Ticket Response Required : Yes

 poc.py is attached



 On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT 
 r...@openssl.org
 wrote:

  Hi,
 
  I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
  bytes for each connection request.
 
  Patch is attached.
 
 
  ___
  openssl-dev mailing list
  To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 
 


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Matt Caswell via RT]

On Thu Jan 15 10:38:58 2015, sidhpurwala.huza...@gmail.com wrote:
 Hi,

 I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
 bytes for each connection request.

 Patch is attached.

I'm not seeing this memory leak. The kctx object should be being freed in the
call to SSL_free - and in my tests it was being. How are you testing this, and
how have you determined that there was a leak?

Thanks

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Huzaifa Sidhpurwala via RT]

Hi,

I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
bytes for each connection request.

Patch is attached.



patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message

[Praveen Kariyanahalli via RT]

Seeing the memory leak (process DTLS server) in the latest released 1.01k
version on the server side. Any clue as to how to get this fixed?

Regards
-Praveen Kariyanahalli

==1162== 36,480 (1,920 direct, 34,560 indirect) bytes in 30 blocks are
definitely lost in loss record 119 of 130
==1162==at 0x4A08219: calloc (vg_replace_malloc.c:623)
==1162==by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170)
==1162==by 0x5BFDC86: default_malloc_ex (mem.c:79)
==1162==by 0x5BFE33D: CRYPTO_malloc (mem.c:312)
==1162==by 0x5D24C9D: pitem_new (pqueue.c:73)
==1162==by 0x595A31F: dtls1_buffer_message (d1_both.c:1267)
==1162==by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629)
==1162==by 0x594E439: dtls1_accept (d1_srvr.c:430)
==1162==by 0x595D8A4: SSL_accept (ssl_lib.c:934)
==1162==by 0x5954BBF: dtls1_listen (d1_lib.c:515)
==1162==by 0x59544DA: dtls1_ctrl (d1_lib.c:271)
==1162==by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087)
==1162==by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887)
==1162==by 0x54C2162: event_persist_closure (event.c:1301)
==1162==by 0x54C2271: event_process_active_single_queue (event.c:1345)
==1162==by 0x54C2540: event_process_active (event.c:1420)
==1162==by 0x54C2BA7: event_base_loop (event.c:1621)
==1162==by 0x41C0B6: vbond_main (vdaemon.c:5428)
==1162==by 0x41E096: main (vdaemon.c:6017)
==1162==
==1162== LEAK SUMMARY:
==1162==definitely lost: 4,032 bytes in 68 blocks
==1162==by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170)
==1162==by 0x5BFDC86: default_malloc_ex (mem.c:79)
==1162==by 0x5BFE33D: CRYPTO_malloc (mem.c:312)
==1162==by 0x5D24C9D: pitem_new (pqueue.c:73)
==1162==by 0x595A31F: dtls1_buffer_message (d1_both.c:1267)
==1162==by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629)
==1162==by 0x594E439: dtls1_accept (d1_srvr.c:430)
==1162==by 0x595D8A4: SSL_accept (ssl_lib.c:934)
==1162==by 0x5954BBF: dtls1_listen (d1_lib.c:515)
==1162==by 0x59544DA: dtls1_ctrl (d1_lib.c:271)
==1162==by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087)
==1162==by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887)
==1162==by 0x54C2162: event_persist_closure (event.c:1301)
==1162==by 0x54C2271: event_process_active_single_queue (event.c:1345)
==1162==by 0x54C2540: event_process_active (event.c:1420)
==1162==by 0x54C2BA7: event_base_loop (event.c:1621)
==1162==by 0x41C0B6: vbond_main (vdaemon.c:5428)
==1162==by 0x41E096: main (vdaemon.c:6017)
==1162==
==1162== LEAK SUMMARY:
==1162==definitely lost: 4,032 bytes in 68 blocks
==1162==indirectly lost: 41,024 bytes in 128 blocks
==1162==  possibly lost: 9,160 bytes in 109 blocks
==1162==still reachable: 1,296,276 bytes in 21,109 blocks
==1162== suppressed: 0 bytes in 0 blocks
==1162== Reachable blocks (those to which a pointer was found) are not
shown.
==1162== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==1162==
==1162== For counts of detected and suppressed errors, rerun with: -v
==1162== ERROR SUMMARY: 46 errors from 46 contexts (suppressed: 1 from 1)

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Huzaifa Sidhpurwala]

Here is how to test it:

openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \
/CN=localhost -nodes -batch -sha256

valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433

./poc.py

Every run of poc.py causes 56 byte memory leak:

==11278== HEAP SUMMARY:
==11278== in use at exit: 910,716 bytes in 20,383 blocks
==11278==   total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
allocated
==11278==
==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823
==11278==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-
amd64-linux.so)
==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
==11278==by 0x436387: sv_body (s_server.c:2004)
==11278==by 0x44AC30: do_server (s_socket.c:324)
==11278==by 0x439C36: s_server_main (s_server.c:1901)
==11278==by 0x419377: do_cmd (openssl.c:489)
==11278==by 0x41906D: main (openssl.c:381)
==11278==
==11278== LEAK SUMMARY:
==11278==definitely lost: 56 bytes in 1 blocks
==11278==indirectly lost: 0 bytes in 0 blocks
==11278==  possibly lost: 0 bytes in 0 blocks
==11278==still reachable: 910,660 bytes in 20,382 blocks
==11278== suppressed: 0 bytes in 0 blocks
==11278== Reachable blocks (those to which a pointer was found) are not shown.
==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11278==
==11278== For counts of detected and suppressed errors, rerun with: -v
==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)



Acknowledgement Text Required: Yes
Community Trackers Required  : Yes
Ticket Response Required : Yes

poc.py is attached



On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:

 Hi,

 I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
 bytes for each connection request.

 Patch is attached.


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


#!/usr/bin/python

import socket

# a SSL 3.0 Client Hello with no ciphers and default compression method (null)
s = bytearray(b\x16\x03\x00\x00+\x01\x00\x00\'\x03\x00\x00\x00\x00\x00\x00 +
b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 +
b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((127.0.0.1, 4433))

sock.sendall(s)
sock.close()
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Huzaifa Sidhpurwala via RT]

Here is how to test it:

openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -subj \
/CN=localhost -nodes -batch -sha256

valgrind --leak-check=full openssl s_server -key localhost.key -cert \
localhost.crt -accept 4433

./poc.py

Every run of poc.py causes 56 byte memory leak:

==11278== HEAP SUMMARY:
==11278== in use at exit: 910,716 bytes in 20,383 blocks
==11278==   total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
allocated
==11278==
==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of 823
==11278==at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-
amd64-linux.so)
==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
==11278==by 0x436387: sv_body (s_server.c:2004)
==11278==by 0x44AC30: do_server (s_socket.c:324)
==11278==by 0x439C36: s_server_main (s_server.c:1901)
==11278==by 0x419377: do_cmd (openssl.c:489)
==11278==by 0x41906D: main (openssl.c:381)
==11278==
==11278== LEAK SUMMARY:
==11278==definitely lost: 56 bytes in 1 blocks
==11278==indirectly lost: 0 bytes in 0 blocks
==11278==  possibly lost: 0 bytes in 0 blocks
==11278==still reachable: 910,660 bytes in 20,382 blocks
==11278== suppressed: 0 bytes in 0 blocks
==11278== Reachable blocks (those to which a pointer was found) are not shown.
==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11278==
==11278== For counts of detected and suppressed errors, rerun with: -v
==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)



Acknowledgement Text Required: Yes
Community Trackers Required  : Yes
Ticket Response Required : Yes

poc.py is attached



On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:

 Hi,

 I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
 bytes for each connection request.

 Patch is attached.


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



#!/usr/bin/python

import socket

# a SSL 3.0 Client Hello with no ciphers and default compression method (null)
s = bytearray(b\x16\x03\x00\x00+\x01\x00\x00\'\x03\x00\x00\x00\x00\x00\x00 +
b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 +
b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00)

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((127.0.0.1, 4433))

sock.sendall(s)
sock.close()
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Matt Caswell via RT]

On Thu Jan 15 14:25:54 2015, sidhpurwala.huza...@gmail.com wrote:
 Here is how to test it:

 openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
 -subj \
 /CN=localhost -nodes -batch -sha256

 valgrind --leak-check=full openssl s_server -key localhost.key -cert \
 localhost.crt -accept 4433

 ./poc.py

 Every run of poc.py causes 56 byte memory leak:

 ==11278== HEAP SUMMARY:
 ==11278== in use at exit: 910,716 bytes in 20,383 blocks
 ==11278== total heap usage: 37,712 allocs, 17,329 frees, 2,596,814
 bytes
 allocated
 ==11278==
 ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658
 of 823

What version of OpenSSL/platform are you running? Is this with vanilla OpenSSL
source, or with OS pre-installed binaries?

I'm not seeing this. I've tried on 1.0.1 and 1.0.0.

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3660] Memory leak in s_server.c

[Huzaifa Sidhpurwala]

This is openssl-1.0.1k on Fedora 21 x86_64, but it should not matter, here
is a brief analysis:

Consider sv_body() in server.c

2237 con=SSL_new(ctx);

Here a new context is initialized. From ssl_lib.c:295, this also causes the
krb context to be initialized via

 295 s-kssl_ctx = kssl_ctx_new();

So SSL_new basically also allocates memory for con-kssl

Later in sv_body() at line 2252:

2252   if ((kctx = kssl_ctx_new()) != NULL)
2253 {
2254 SSL_set0_kssl_ctx(con, kctx);

This causes con-kssl_ctx to be rewritten by kctx, in doing so 56 bytes of
previously allocated memory is lost
and hence the memory leak for each connection made.


On Thu, Jan 15, 2015 at 6:55 PM, Huzaifa Sidhpurwala via RT r...@openssl.org
wrote:

 Here is how to test it:

 openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt
 -subj \
 /CN=localhost -nodes -batch -sha256

 valgrind --leak-check=full openssl s_server -key localhost.key -cert \
 localhost.crt -accept 4433

 ./poc.py

 Every run of poc.py causes 56 byte memory leak:

 ==11278== HEAP SUMMARY:
 ==11278== in use at exit: 910,716 bytes in 20,383 blocks
 ==11278==   total heap usage: 37,712 allocs, 17,329 frees, 2,596,814 bytes
 allocated
 ==11278==
 ==11278== 56 bytes in 1 blocks are definitely lost in loss record 658 of
 823
 ==11278==at 0x4C2745D: malloc (in
 /usr/lib64/valgrind/vgpreload_memcheck-
 amd64-linux.so)
 ==11278==by 0x5A6AD12: CRYPTO_malloc (mem.c:308)
 ==11278==by 0x4E81729: kssl_calloc.constprop.0 (kssl.c:790)
 ==11278==by 0x4E759E9: SSL_new (ssl_lib.c:295)
 ==11278==by 0x436387: sv_body (s_server.c:2004)
 ==11278==by 0x44AC30: do_server (s_socket.c:324)
 ==11278==by 0x439C36: s_server_main (s_server.c:1901)
 ==11278==by 0x419377: do_cmd (openssl.c:489)
 ==11278==by 0x41906D: main (openssl.c:381)
 ==11278==
 ==11278== LEAK SUMMARY:
 ==11278==definitely lost: 56 bytes in 1 blocks
 ==11278==indirectly lost: 0 bytes in 0 blocks
 ==11278==  possibly lost: 0 bytes in 0 blocks
 ==11278==still reachable: 910,660 bytes in 20,382 blocks
 ==11278== suppressed: 0 bytes in 0 blocks
 ==11278== Reachable blocks (those to which a pointer was found) are not
 shown.
 ==11278== To see them, rerun with: --leak-check=full --show-leak-kinds=all
 ==11278==
 ==11278== For counts of detected and suppressed errors, rerun with: -v
 ==11278== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
 


 Acknowledgement Text Required: Yes
 Community Trackers Required  : Yes
 Ticket Response Required : Yes

 poc.py is attached



 On Thu, Jan 15, 2015 at 3:08 PM, Huzaifa Sidhpurwala via RT 
 r...@openssl.org
 wrote:

  Hi,
 
  I found a memory leak in s_server.c. On my x86_64 machine, this leaks 56
  bytes for each connection request.
 
  Patch is attached.
 
 
  ___
  openssl-dev mailing list
  To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
 
 


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev