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@xxxxxxxxxxxx> 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-----
