Bug#784112: /usr/sbin/saslauthd: saslauthd segfaults

Tue May 12 09:08:21 UTC 2015

I have changed the backend to pam and had no segfaults for the last 3 days.
Seem like only the shadow backend has this issue.

On Fri, May 8, 2015 at 9:10 AM, Thomas Kupka <itchy.de at gmail.com> wrote:

>
> On Wed, 6 May 2015 09:10:15 -0500 Dan White <dwhite at olp.net> wrote:
>
> > Can you get a backtrace from the core dump, and debug output, e.g.:
> >
> > saslauthd -d -c -m /var/spool/postfix/
>
> It does not seem that debug gives out any interesting information. Here
> are the last lines from when the child processes died:
>
> saslauthd[19194] :do_auth         : auth success: [user=thomas]
> [service=imap] [realm=] [mech=shadow]
> saslauthd[19194] :do_request      : response: OK
> saslauthd[19195] :rel_accept_lock : released accept lock
> saslauthd[19193] :get_accept_lock : acquired accept lock
> saslauthd[19193] :rel_accept_lock : released accept lock
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19193] :do_auth         : auth failure: [user=noauth]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19193] :get_accept_lock : acquired accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=spam]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19193] :rel_accept_lock : released accept lock
> saslauthd[19193] :do_auth         : auth failure: [user=test]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=info]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19193] :get_accept_lock : acquired accept lock
> saslauthd[19193] :rel_accept_lock : released accept lock
> saslauthd[19193] :do_auth         : auth failure: [user=admin]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=administrator]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19193] :get_accept_lock : acquired accept lock
> saslauthd[19193] :rel_accept_lock : released accept lock
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=postmaster]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=sales]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=support]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=webmaster]
> [service=smtp] [realm=] [mech=shadow] [reason=Incorrect password]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=help]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=contact]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=office]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
> saslauthd[19194] :do_auth         : auth failure: [user=staff]
> [service=smtp] [realm=] [mech=shadow] [reason=Invalid username]
> saslauthd[19194] :get_accept_lock : acquired accept lock
> saslauthd[19194] :rel_accept_lock : released accept lock
>
> The failed authentication attempts are certainly malicious software trying
> out default credentials but they seem to be handled normally.
>
> > This backend doesn't get used much these days. pam should functionally
> > replace it. Does it also produce a segfault?
>
> I will try this. I have shadow backend running for about 10 years now and
> never had this urge to change it.
>
> Thomas
>
> On Wed, May 6, 2015 at 4:10 PM, Dan White <dwhite at olp.net> wrote:
>
>> On 05/03/15 10:24 +0200, Thomas Kupka wrote:
>>
>>> Package: sasl2-bin
>>> Version: 2.1.26.dfsg1-13
>>> Severity: important
>>> File: /usr/sbin/saslauthd
>>>
>>> Dear Maintainer,
>>>
>>> since upgrading to Jessie, all saslauthd processes segfault on a
>>> multiple daily basis:
>>>
>>> May  3 06:26:12 mail kernel: [22739.740552] saslauthd[763]: segfault at
>>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so
>>> [7faffd557000+19f000]
>>> May  3 06:26:12 mail kernel: [22739.928344] saslauthd[739]: segfault at
>>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so
>>> [7faffd557000+19f000]
>>> May  3 06:26:12 mail kernel: [22740.127304] saslauthd[760]: segfault at
>>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so
>>> [7faffd557000+19f000]
>>> May  3 10:04:24 mail kernel: [35831.420577] saslauthd[761]: segfault at
>>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so
>>> [7faffd557000+19f000]
>>> May  3 10:04:24 mail kernel: [35831.607218] saslauthd[762]: segfault at
>>> 0 ip 00007faffd5d8c8a sp 00007ffda85ebe48 error 4 in libc-2.19.so
>>> [7faffd557000+19f000]
>>> May  3 10:04:24 mail postfix/smtpd[17269]: warning: SASL authentication
>>> failure: cannot connect to saslauthd server: Connection refused
>>>
>>
>> Can you get a backtrace from the core dump, and debug output, e.g.:
>>
>> saslauthd -d -c -m /var/spool/postfix/var/run/saslauthd -a shadow
>>
>> I can't reproduce your segfault on my unstable system running
>> 2.1.26.dfsg1-13. However, I'm several version behind on some of the linked
>> libraries.
>>
>>  -- Configuration Files:
>>> /etc/default/saslauthd changed:
>>> START=yes
>>> DESC="SASL Authentication Daemon"
>>> NAME="saslauthd"
>>> MECHANISMS="shadow"
>>>
>>
>> This backend doesn't get used much these days. pam should functionally
>> replace it. Does it also produce a segfault?
>>
>> --
>> Dan White
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-cyrus-sasl2-debian-devel/attachments/20150512/2fcc883d/attachment.html>