Published: 18 July 2013
Cyrus SASL 2.1.23, 2.1.26, and earlier does not properly handle when a NULL value is returned upon an error by the crypt function as implemented in glibc 2.17 and later, which allows remote attackers to cause a denial of service (thread crash and consumption) via (1) an invalid salt or, when FIPS-140 is enabled, a (2) DES or (3) MD5 encrypted password, which triggers a NULL pointer dereference.
Launchpad, Ubuntu, Debian
|Ubuntu 14.04 ESM (Trusty Tahr)||
Upstream: http://git.cyrusimap.org/cyrus-sasl/commit/?id=dedad73e5e7a75d01a5f3d5a6702ab8ccd2ff40d (trunk)
Other: http://sourceforge.net/projects/miscellaneouspa/files/glibc217/cyrus-sasl-2.1.23-glibc217-crypt.diff (2.1.23)
Other: http://sourceforge.net/projects/miscellaneouspa/files/glibc217/cyrus-sasl-2.1.26-glibc217-crypt.diff (2.1.26)
NULL return from crypt() if the salt isn't sane Upgraded to medium, bug report shows remote attackers can disable the sasl service by repeating the attack; THREADS=0 configuration is a work-around that may help to prevent abuse.
eglibc only returns NULL from crypt() in 2.17+, so quantal and older are not affected. 2015-09-25: patch was dropped by mistake in debian's 2.1.26 package, fixed again in 2.1.26.dfsg1-14