Re: [openssl-dev] Memory leak in application when we use ECDH
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
: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 40016 3728 2740 S 10.7 0.1 0:03.42 openssl > > > top - 10:17:16 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > 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 > Mem: 3924288k total, 3759824k used, 164464k free,78384k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 40124 3748 2740 S 11.3 0.1 0:03.76 openssl > > --- > > top - 10:23:10 up 46 days, 1:36, 2 users, load average: 0.03, 0.05, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > 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 > Mem: 3924288k total, 3756048k used, 168240k free,75888k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216576k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 42392 6048 2740 S 10.7 0.2 0:41.95 openssl > > > top - 10:23:13 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): 3.2%us, 1.3%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756064k used, 168224k free,75904k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 42392 6068 2740 S 10.7 0.2 0:42.27 openssl > > > top - 10:23:16 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > 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 > Mem: 3924288k total, 3756188k used, 168100k free,75912k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 42392 6088 2740 R 11.0 0.2 0:42.60 openssl > > > top - 10:23:19 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): 3.1%us, 1.2%sy, 1.6%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756528k used, 167760k free,75920k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216584k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 27303 root 20 0 42392 6108 2740 S 10.7 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
Re: [openssl-dev] Memory leak in application when we use ECDH
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
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
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
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
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
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
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
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
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
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
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
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
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
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
AuthorDate: Fri Dec 4 22:22:31 2015 +0100
Commit: Kurt Roeckx
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
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
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 ((encodedPoint == NULL) || (bn_ctx == NULL)) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,
