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

Tue May 12 13:42:03 UTC 2015

Thomas,

Can you provide a reproducible case? e.g., does this happen on the first
authentication attempt after starting saslauthd (with the shadow backend),
or are there other factors at play that you can identify?

On 05/12/15 11:08 +0200, Thomas Kupka wrote:
>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
>>>
>>
>>
>>

>_______________________________________________
>Pkg-cyrus-sasl2-debian-devel mailing list
>Pkg-cyrus-sasl2-debian-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-cyrus-sasl2-debian-devel

-- 
Dan White
BTC Broadband
Network Admin Lead
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwhite at olp.net
http://www.btcbroadband.com