Bug#784112: /usr/sbin/saslauthd: saslauthd segfaults
Dan White
dwhite at olp.net
Wed May 13 14:00:30 UTC 2015
Thomas,
I've installed a standard jessie/amd64 installation running the same
versions you are and I cannot reproduce. I've tried testsaslauthd, pop3d,
and smtptest using both a known good username and a bad username
(webmaster), using a for loop to simulate rapid connections.
If you can enable core dumps for saslauthd, and install libc6-dbg and
cyrus-sasl2-dbg, in your production environment, please obtain a gdb
backtrace.
On 05/12/15 16:09 +0200, Thomas Kupka wrote:
>Dan,
>
>the only lead I could have is a correlation between peaks of failed login
>attempts (from malicious sources most likely, at a rate of precisely one
>attempt every 5 seconds) and the segfaults. Does this help?
>
>extract from mail.log:
>May 10 10:17:50 mail cyrus/pop3[23539]: badlogin: no-data [60.29.221.174]
>plaintext test SASL(-13): authentication failure: checkpass failed
>May 10 10:17:55 mail cyrus/pop3[23540]: badlogin: no-data [60.29.221.174]
>plaintext test SASL(-13): authentication failure: checkpass failed
>May 10 10:18:00 mail cyrus/pop3[23541]: badlogin: no-data [60.29.221.174]
>plaintext test SASL(-13): authentication failure: checkpass failed
>
>extract from messages:
>May 10 10:18:09 mail kernel: [641457.138137] saslauthd[18768]: segfault at
>0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in libc-2.19.so
>[7fdf75137000+19f000]
>May 10 10:18:14 mail kernel: [641461.917719] saslauthd[18773]: segfault at
>0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in libc-2.19.so
>[7fdf75137000+19f000]
>May 10 10:18:19 mail kernel: [641466.650182] saslauthd[18764]: segfault at
>0 ip 00007fdf751b8c8a sp 00007ffd3cf92e58 error 4 in libc-2.19.so
>[7fdf75137000+19f000]
>
>After this peak was over, there have been no more segfaults for the next 8
>hours.
>
>On Tue, May 12, 2015 at 3:42 PM, Dan White <dwhite at olp.net> wrote:
>
>> 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
>>
--
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
More information about the Pkg-cyrus-sasl2-debian-devel
mailing list