[a.goo0h@gmail.com: Re: Bug#379810: saslauthd memory leak]

Sat Apr 28 13:15:10 UTC 2007

This appeared on the cyrus-sasl upstream list in reply to a query of
mine.  Perhaps it might be useful here as well.

Regards,

-Roberto

----- Forwarded message from Amos <a.goo0h at gmail.com> -----

Date: Wed, 25 Apr 2007 09:25:30 -0500
From: Amos <a.goo0h at gmail.com>
To: cyrus-sasl at lists.andrew.cmu.edu
Subject: Re: Bug#379810: saslauthd memory leak
X-Mailman-Handler: $Id: mm-handler,v 1.2 2002/04/05 19:41:09 bwarsaw Exp $
X-BeenThere: cyrus-sasl at lists.andrew.cmu.edu

I've definitely observed a memory leak when saslauthd is using PAM on
Solaris 10 (SPARC). Instead of using "-n 0" I set up a cron job to
restart saslauthd weekly at 5AM on a Sunday. Fortunately when I set up
both saslauthd and cyrus under SMF, I did not make saslauthd a
dependency of cyrus, so I can restart saslauthd whenever necessary
without cyrus restarting.

I'm not sure where the leak lies. The little bit of time I've browsed
through the saslauthd code it *looks* like it is straightforward PAM
stuff. Furthermore, unless my memory is failing me, I believe that
back with Solaris 8 there were in fact some known leaks in the PAM
libraries, especially pam_ldap. I don't know if that's still the case.
Haven't had a chance to dig through sunsolve.

On 4/24/07, Roberto C. Sánchez <roberto at connexer.com> wrote:
>Might this addition to a Debian bug report about saslauthd leaking
>memory be helpful?
>
>Regards,
>
>-Roberto
>
>On Tue, Mar 20, 2007 at 04:52:26PM +0100, Gabor Gombas wrote:
>> Hi,
>>
>> I got annoyed by saslauthd consuming more than 2Gig of RAM so I started
>> looking into this issue. My findings:
>>
>> - The leak does NOT happen on successful authentication. I sent 500000
>>   valid auth. requests to saslauthd and its memory usage did not
>>   increase.
>>
>> - I sent just a couple of invalid authentication requests and
>>   saslauthd's memory usage started to climb. So this is a trivially
>>   exploitable remote DoS (send a large amount of bad passwords to any
>>   sasl-using service and wait until the OOM killer kicks in and renders
>>   your box useless).
>>
>> - The leak is NOT related to libpam-mysql, it happens with the plain
>>   pam_unix module as well.
>>
>> - When using just pam_unix, valgrind gives the following trace segment:
>>
>> ==17824== 68 bytes in 17 blocks are definitely lost in loss record 7 of 7
>> ==17824==    at 0x40064B0: malloc (vg_replace_malloc.c:149)
>> ==17824==    by 0x425AAF12: (within /lib/ld-2.5.so)
>> ==17824==    by 0x425AC5B4: (within /lib/ld-2.5.so)
>> ==17824==    by 0x425B6450: (within /lib/ld-2.5.so)
>> ==17824==    by 0x425B2401: (within /lib/ld-2.5.so)
>> ==17824==    by 0x425B5E9D: (within /lib/ld-2.5.so)
>> ==17824==    by 0x42709C2C: (within /lib/i686/cmov/libdl-2.5.so)
>> ==17824==    by 0x425B2401: (within /lib/ld-2.5.so)
>> ==17824==    by 0x4270A2AB: (within /lib/i686/cmov/libdl-2.5.so)
>> ==17824==    by 0x42709B60: dlopen (in /lib/i686/cmov/libdl-2.5.so)
>> ==17824==    by 0x4352838F: (within /lib/libpam.so.0.79)
>> ==17824==    by 0x4352852B: (within /lib/libpam.so.0.79)
>> ==17824==    by 0x435292F3: _pam_init_handlers (in /lib/libpam.so.0.79)
>> ==17824==    by 0x4352726E: pam_start (in /lib/libpam.so.0.79)
>> ==17824==    by 0x804B1F4: auth_pam (auth_pam.c:207)
>>
>> The number of lost blocks equals to the invalid authentication requests
>> I sent to saslauthd. This seems to suggest that something forgets to
>> clean up when an authentication request fails.
>>
>> The amount of leaked memory seems to be dependent on the PAM module
>> being used. pam_unix seems to be the 'nicest'; with libpam_mysql, I get
>> about 60 KiB of memory lost for every failed authentication attempt,
>> according to 'ps' output.
>>
>> Gabor
>>
>
>--
>Roberto C. Sánchez
>http://people.connexer.com/~roberto
>http://www.connexer.com
>

----- End forwarded message -----

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20070428/a5766c3e/attachment.pgp