date:20170327

Re: [openssl-dev] Code Health Tuesday - documentation!

2017-03-27 Thread Matt Caswell

Just a reminder about this event taking place tomorrow!

Matt

On 23/03/17 17:57, Matt Caswell wrote:
> 
> Hi all
> 
> Our next "Code Health Tuesday" event will be on Tuesday 28th March.
> 
> We've seen some great contributions during our last two events with many
> significant improvements merged as a result. We'd like to continue that
> trend with our next theme - documentation.
> 
> Just find some missing documentation, write it and send us a PR on our
> github site. Or help us fix incorrect or out-of-date documentation, or
> broken links, etc.
> 
> Thanks!
> 
> Matt
> 
> 
> FAQ:
> 
> Q: How do I participate?
> A: Find something to document. Create a Github pull request and  put
> “code health” in the title. We’ll be monitoring Github for quick turnaround.
> 
> Q: Which branches should I target?
> A: You should target master. If documentation applies to earlier
> releases then please indicate which ones in the PR. Sometimes there are
> subtle differences between the different releases, so it may be
> necessary to create a different PR for older branches.
> 
> Q: What form should the documentation take?
> A: All our documentation is in POD file format. Take a look in the doc
> directory and read a few of the pages to get used to our style. The
> doc/man3/BIO_printf.pod file is a good, recently written example. If you
> are providing missing documentation consider whether it should appear in
> a new POD file, or whether it should be added to an existing one.
> You can use the "doc-nits" script to run some basic checks on the
> documentation you have written (run "make doc-nits").
> 
> Q: Do you have any tools to find what to document?
> A: Yes, the doc-nits tool (in the util sub-dir) can provide some useful
> info:
> ./util/find-doc-nits –l (references to non-existing POD pages)
> ./util/find-doc-nits –u (all undocumented public functions)
> 
-- 
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

2017-03-27 Thread 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
> Mem:   3924288k total,  3757980k used,   166308k free,78232k buffers
> Swap:  8388604k total,   999556k used,  7389048k free,   219744k cached
> 
>   PID USER

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

2017-03-27 Thread 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 free,   219732k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 27303 root  20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl
> 
> 
> top - 10:16:49 up 46 days,

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

2017-03-27 Thread Richard Levitte

Are you confident this is the same leak that you have experienced?
Your original complaint was about keys created with the callback
that's added with SSL_set_tmp_ecdh_callback(), and I have to point out
that s_server doesn't provide such a callback.  In fact,
SSL_set_tmp_ecdh_callback() isn't called anywhere in the OpenSSL
source.

That doesn't mean you haven't found the same leak, if there is a leak
(I'm not going to rule out some other explanation), it might simply
clarify that targeting on the EC_KEY returned from the callback might
make us blind for something else that's related.

Cheers,
Richard

In message 
<25d2ec755404b4409f263ac6d050febb2a108...@az-ffexmb03.global.avaya.com> on Mon, 
27 Mar 2017 08:40:30 +, "Mody, Darshan (Darshan)"  
said:

darshanmody> Matt, Richard,
darshanmody> 
darshanmody> I have not created any patch. Instead I am using s_server app 
provided from Openssl. Below is the server side command run
darshanmody> 
darshanmody> openssl s_server -accept  -key  -cert 
 -CAfile   
-verify 
darshanmody> 
darshanmody> On the client side I am running script below
darshanmody> 
darshanmody> #/bin/sh
darshanmody> 
darshanmody> while [ 1 ]
darshanmody> do
darshanmody>  openssl s_client -connect : -cert 
 -key  &>/dev/null
darshanmody> done
darshanmody> 
darshanmody> 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. 
darshanmody> 
darshanmody> 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.
darshanmody> 
darshanmody> top - 10:16:37 up 46 days,  1:29,  2 users,  load average: 0.03, 
0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> 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
darshanmody> Mem:   3924288k total,  3757716k used,   166572k free,78200k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219736k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 39908 3528 2740 S  0.0  0.1   0:00.00 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:16:40 up 46 days,  1:29,  2 users,  load average: 0.03, 
0.06, 0.08
darshanmody> Tasks:   1 total,   1 running,   0 sleeping,   0 stopped,   0 
zombie
darshanmody> 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
darshanmody> Mem:   3924288k total,  3757856k used,   166432k free,78208k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 39908 3532 2740 R  4.3  0.1   0:00.13 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:16:43 up 46 days,  1:29,  2 users,  load average: 0.03, 
0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> 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
darshanmody> Mem:   3924288k total,  3757980k used,   166308k free,78232k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 39908 3544 2740 S  7.0  0.1   0:00.34 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:16:46 up 46 days,  1:30,  2 users,  load average: 0.03, 
0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> 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
darshanmody> Mem:   3924288k total,  3757964k used,   166324k free,78248k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219732k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303 root  20   0 39908 3560 2740 S  6.7  0.1   0:00.54 
openssl
darshanmody> 
darshanmody> 
darshanmody> top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 
0.06, 0.08
darshanmody> Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 
zombie
darshanmody> Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  
0.2%si,  0.0%st
darshanmody> Mem:   3924288k total,  3758212k used,   166076k free,78264k 
buffers
darshanmody> Swap:  8388604k total,   999556k used,  7389048k free,   219744k 
cached
darshanmody> 
darshanmody>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  
COMMAND
darshanmody> 27303

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

2017-03-27 Thread Mody, Darshan (Darshan)

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   -verify 

On the client side I am running script below

#/bin/sh

while [ 1 ]
do
 openssl s_client -connect : -cert  -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 free,   219732k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
27303 root  20   0 39908 3560 2740 S  6.7  0.1   0:00.54 openssl


top - 10:16:49 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.1%sy,  0.0%ni, 96.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   3924288k total,  3758212k used,   166076k free,78264k 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 3572 2740 S  8.0  0.1   0:00.78 openssl


top - 10:16:52 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.2%sy,  0.0%ni, 94.8%id,  0.1%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3758212k used,   166076k free,78288k buffers
Swap:  8388604k total,   999556k used,  7389048k free,   219732k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
27303 root  20   0 39908 3592 2740 S 11.0  0.1   0:01.11 openssl


top - 10:16:55 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  1.3%sy,  0.1%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   3924288k total,  3758584k used,   165704k free,78288k 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 3608 2740 S 11.3  0.1   0:01.45 openssl


top - 10:16:58 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  1.6%sy,  0.0%ni, 94.7%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Mem:   3924288k total,  3758864k used,   165424k free,78296k 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 3628 2740 S 11.3  0.1   0:01.79 openssl


top - 10:17:01 up 46 days,  1:30,  2 users,  load average: 0.02, 0.06, 0.08
Tasks:   1 total,   0

[openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

2017-03-27 Thread Raja ashok

Hi,

I feel there is a check missing in ssl3_write_bytes, in case of handling write 
failure.

Consider SSL_write is called with 2 bytes buffer, then internally in 
ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send 
failed for the second record then we store the states internally (wnum, 
wpend_tot and wpend_buf) and return back the result.

Later application has to call SSL_write with same buffer, if it calls with 
different buffer of length 100 byte then we fail that in ssl3_write_bytes using 
the check (len < tot).

But consider application calls with buffer of size 18000 bytes and 
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not 
succeed as tot is 16384. Then it will call ssl3_write_pending to send the 
remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now 
tot will have 2.

Later there is a check (tot == len), this will not succeed. Then directly we 
are doing n = (len - tot), this will overflow and store a value close to 2^32 
in n. Then it will cause out of bound access to the application buffer "buf".

I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before 
calling ssl3_write_pending.

if ((len < tot) || (len < (tot + s->s3->wpend_tot))){
SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH);
return (-1);
}

Note : I am referring 1.0.2k version of OpenSSL.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

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

Re: [openssl-dev] Code Health Tuesday - documentation!

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

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

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

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

[openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing

6 matches

Site Navigation

Mail list logo

Footer information