Bug#379810: saslauthd memory leak

[Amos]

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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFGLpvF5SXWIKfIlGQRAikjAJwO9tmCwsIfQNWZjyDnmU15BmaXDwCfbt8n
> 2icMTnOtQmJlH6HscEkt79o=
> =6LGj
> -----END PGP SIGNATURE-----
>
>