saslauthd[26791]: segfault at 0 ip b71de6f1 sp bfcd2d9c error 4 in libc-2.17.so[b7160000+1ad000]

....if anyone else is suffering this I installed fail2ban as a workaround, the attacker's IP gets banned before SASL falls over.

Hi all

I can reproduce the problem when I run saslauthd with authmech shadow:

    saslauthd -a shadow

and then try to authenticate users that have a crippled /etc/shadow entry. By crippled I mean ! or * as password entry, as for root, mail, nobody.

When I run the 2.1.25 stock source with debugging symbols in gdb with "-a shadow -n 1 -d -m /var/run/saslauthd/mux" as param, I get:

Program received signal SIGSEGV, Segmentation fault.
0xb7e6e6f1 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) where
#0 0xb7e6e6f1 in ?? () from /lib/i386-linux-gnu/libc.so.6
#1 0xb7e6e326 in strdup () from /lib/i386-linux-gnu/libc.so.6
#2 0x0804b910 in auth_shadow (login=0xbffff098 "root",
    password=0xbffff199 "dfsdf", service=0xbffff29a "ldap",
    realm=0xbffff39b "") at auth_shadow.c:188
#3 0x0804ed3f in do_auth (_login=_login@entry=0xbffff098 "root",
    password=password@entry=0xbffff199 "dfsdf",
    service=service@entry=0xbffff29a "ldap", realm=realm@entry=0xbffff39b "")
    at saslauthd-main.c:410
#4 0x0804dd17 in do_request (conn_fd=conn_fd@entry=9) at ipc_unix.c:426
#5 0x0804e547 in ipc_loop () at ipc_unix.c:277
#6 0x080499c1 in main (argc=8, argv=0xbffff5e4) at saslauthd-main.c:369

Offending line is:

      cpw = strdup((const char *)crypt(password, sp->sp_pwdp));

where crypt() returns NULL for the crippled shadow entries. Proposed patch:

    char *encpwd = crypt(password, sp->sp_pwdp);
    if (encpwd == NULL) {
        if (flags & VERBOSE) {
            syslog(LOG_DEBUG, "DEBUG: auth_shadow: crypt returned NULL");
        }
        RETURN("NO");
    }
    cpw = strdup((const char *)encpwd);

BTW, shouldn't saslauthd use crypt_r(), it being a multi-threaded beasty? ;o)

I think this hasn't been addressed in part because it didn't get a CVE number: http://openwall.com/lists/oss-security/2013/07/12/4

Since the service appears to be restarting without qualm, I can see why it didn't get a CVE, but this does seem less than awesome.

Mancha made a lot of patches for services when the crypt() change happened, here's an email from him with upstream patch and two backported patches: http://openwall.com/lists/oss-security/2013/07/12/3

Hi

Thanks. Also note the use of crypt() in a multithreaded application. Must be crypt_r().

CU,
      Arno

Seth Arnold <email address hidden> wrote:
>I think this hasn't been addressed in part because it didn't get a CVE
>number: http://openwall.com/lists/oss-security/2013/07/12/4
>
>Since the service appears to be restarting without qualm, I can see why
>it didn't get a CVE, but this does seem less than awesome.
>
>Mancha made a lot of patches for services when the crypt() change
>happened, here's an email from him with upstream patch and two
>backported patches: http://openwall.com/lists/oss-security/2013/07/12/3
>
>--
>You received this bug notification because you are subscribed to the
>bug
>report.
>https://bugs.launchpad.net/bugs/1187001
>
>Title:
> saslauthd[26791]: segfault at 0 ip b71de6f1 sp bfcd2d9c error 4 in
> libc-2.17.so[b7160000+1ad000]
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1187001/+subscriptions

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Are you confident about multi-threading? I don't see any linker commands to link against the threading libraries in our build logs: https://launchpadlibrarian.net/92810645/buildlog_ubuntu-precise-amd64.cyrus-sasl2_2.1.25.dfsg1-3_BUILDING.txt.gz and I also see extensive use of fork(2) in the upstream git: http://git.cyrusimap.org/cyrus-sasl/tree/saslauthd/saslauthd-main.c?id=dedad73e5e7a75d01a5f3d5a6702ab8ccd2ff40d

From just the five minutes I've looked, I'd say it looks like usual Unix-style preforking server, not threaded server.

Thanks

I think default THREADS=5 in /etc/default/saslauthd, after these all crash [as above] then thats the end of SASL working. (at least that is what happened for me, repeatedly).
Setting this to THREADS=0 has worked around the issue (for me anyway) as it makes it fork instead.

On 02/10/2013 08:09, Seth Arnold wrote:
> Are you confident about multi-threading? I don't see any linker commands
> to link against the threading libraries in our build logs:
> https://launchpadlibrarian.net/92810645/buildlog_ubuntu-precise-amd64
> .cyrus-sasl2_2.1.25.dfsg1-3_BUILDING.txt.gz and I also see extensive
> use of fork(2) in the upstream git: http://git.cyrusimap.org/cyrus-
> sasl/tree/saslauthd/saslauthd-
> main.c?id=dedad73e5e7a75d01a5f3d5a6702ab8ccd2ff40d
>
>>From just the five minutes I've looked, I'd say it looks like usual
> Unix-style preforking server, not threaded server.
>

Hi

I'm not an expert on this. But when compiled with --with-ipctype=doors
it will use pthreads. Also, the auth_shadow.c contains #ifdef _REENTRANT
directives, suggesting possible multi-threaded use.

So someone (perhaps upstream) should make sure the code is safe to use
in all configurations.

CU,
     Arno

Hi. This issue was assigned CVE-2013-4122: http://openwall.com/lists/oss-security/2013/07/13/1

--mancha

I just updated the upstream bugzilla report to reflect the CVE assignment and link my point release patches.

https://bugzilla.cyrusimap.org/show_bug.cgi?id=3803

Mancha, thanks! I'm sorry I overlooked it. (Even worse, I did the triage way back when I forgot about it in the meantime: http://people.canonical.com/~ubuntu-security/cve/2013/CVE-2013-4122.html )

This issue only affects Raring and newer. Already fixed in saucy.

This bug was fixed in the package cyrus-sasl2 - 2.1.25.dfsg1-6ubuntu0.1

---------------
cyrus-sasl2 (2.1.25.dfsg1-6ubuntu0.1) raring-security; urgency=low

  * SECURITY UPDATE: denial of service via invalid salt (LP: #1187001)
    - debian/patches/CVE-2013-4122.patch: properly handle glibc returning
      NULL on an invalid salt in pwcheck/pwcheck_getpwnam.c,
      pwcheck/pwcheck_getspnam.c, saslauthd/auth_getpwent.c,
      saslauthd/auth_shadow.c.
    - CVE-2013-4122
 -- Marc Deslauriers <email address hidden> Mon, 07 Oct 2013 08:40:56 -0400