[stunnel-users] Possible leak in client.c:init_ssl()

[Sven Ulland]

On 04/11/2011 05:13 PM, Michal Trojnara wrote:
> Sven Ulland wrote:
>> The Massif log indicates that most of the memory is allocated
>> through client.c:init_ssl(), by libssl and zlib. I haven't looked
>> too much at the code yet, but could this be related to the high
>> rate of connection resets/timeouts, combined with
>> connection/session reuse?
>
> I guess you're right.  A trivial workaround would be to build
> OpenSSL without zlib.  8-)
>
> BTW: What is your version of OpenSSL?

The initial report was based on OpenSSL 0.9.8g. I then compiled 0.9.8r
without zlib, and it ran well and without any obvious leaks. A massif
output of that run is attached: It shows memory use of 314MB while
idle (after having served a lot of connections). Is it so that the
number of ssl/connections allocated by stunnel is always the maximum
observed throughout the entire runtime, i.e. it never frees up idle
connections? That's not really a problem, I'm just curious.

What I should have done earlier is to check the OpenSSL change log.

"""
Changes between 0.9.8n and 1.0.0  [29 Mar 2010]
[...]
Fix compression algorithm handling: if resuming a session use the
compression algorithm of the resumed session instead of determining it
from client hello again. Don't allow server to change algorithm.
"""

I'm not sure if this was backported to 0.9.8r, but there's also this:

"""
Changes between 0.9.8l and 0.9.8m [25 Feb 2010]
[...]
Modify compression code so it frees up structures without using the
ex_data callbacks. This works around a problem where some applications
call CRYPTO_cleanup_all_ex_data() before application exit (e.g. when
restarting) then use compression (e.g. SSL with compression) later.
This results in significant per-connection memory leaks and has caused
some security issues including CVE-2008-1678 and CVE-2009-4355.
"""

I recompiled 0.9.8r with zlib enabled again, but it's not clear to me
if zlib was actually used in the following run or not. At least there
were no zlib or libz strings in the massif output.

I'll assume it's the OpenSSL issues that were at fault, and then
continue to run with the new lib version. If there is any new
development in the upcoming days, I'll send a follow-up.

sven
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: massif.out.txt
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20110412/69786cf2/attachment.txt>