Bug 476764 – <dev-libs/cyrus-sasl-{2.1.23-r7,2.1.26-r3}: Null pointer deference (CVE-2013-4122)

• Status: RESOLVED FIXED
• Product: Gentoo Security

[Description Agostino Sarubbo 2013-07-13 20:58:01 UTC]

From ${URL} :

Starting with glibc 2.17 (eglibc 2.17), crypt() fails with
EINVAL (w/ NULL return) if the salt violates specifications.
Additionally, on FIPS-140 enabled Linux systems, DES/MD5-encrypted
passwords passed to crypt() fail with EPERM (w/ NULL return).

When authenticating against Cyrus-sasl via mechanisms that use
glibc's crypt (e.g. getpwent or shadow auth. mechs), and this
crypt() returns a NULL as glibc 2.17+ does on above-described
input, the client crashes the authentication daemon resulting
in a DoS.

Upstream fix:
http://git.cyrusimap.org/cyrus-
sasl/commit/?id=dedad73e5e7a75d01a5f3d5a6702ab8ccd2ff40d

Backported fixes (versions 2.1.23 & 2.1.26):
http://sourceforge.net/projects/miscellaneouspa/files/glibc217/cyrus
-sasl-2.1.23-glibc217-crypt.diff
http://sourceforge.net/projects/miscellaneouspa/files/glibc217/cyrus
-sasl-2.1.26-glibc217-crypt.diff



@maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.

[Comment 1 Eray Aslan 2013-07-16 07:26:20 UTC]

@security:  Please stabilize
=dev-libs/cyrus-sasl-2.1.23-r7
=dev-libs/cyrus-sasl-2.1.26-r3

Thank you.

[Comment 2 Jeroen Roovers (RETIRED) 2013-07-16 13:09:39 UTC]

(In reply to Eray Aslan from comment #1)
> @security:  Please stabilize
> =dev-libs/cyrus-sasl-2.1.23-r7
> =dev-libs/cyrus-sasl-2.1.26-r3
> 
> Thank you.

You could actually CC arch teams yourself. Why should security@ do it?

[Comment 3 Chris Reffett (RETIRED) 2013-07-16 23:13:52 UTC]

I'm happy to be requesting the stable. Arches, please stabilize =dev-libs/cyrus-sasl-2.1.23-r7 and =dev-libs/cyrus-sasl-2.1.26-r3, target arches alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86. Thanks!

[Comment 4 Jeroen Roovers (RETIRED) 2013-07-16 23:28:58 UTC]

Click [Add arches:]. :)

And please please put the atoms on separate lines (from each other and from the rest of the blurb).

[Comment 5 Eray Aslan 2013-07-17 06:22:12 UTC]

> You could actually CC arch teams yourself. Why should security@ do it?

Uhm, I thought the security guys wanted to do it themselves.

http://www.gentoo.org/security/en/coordinator_guide.xml :
Once you have determined (and noted for reference on the bug) the needed KEYWORDS, you should Cc: arch teams and ask them to mark the ebuild stable or testing accordingly. To make sure that the arch teams will pick the bug up, don't forget to add "STABLEREQ" to the bug's "Keywords" field.

If the security team ACKSs, I have no problem with adding the arches.

[Comment 6 Jeroen Roovers (RETIRED) 2013-07-17 11:08:51 UTC]

Stable for HPPA.

[Comment 7 Agostino Sarubbo 2013-07-20 18:16:20 UTC]

amd64 stable

[Comment 8 Agostino Sarubbo 2013-07-20 18:16:43 UTC]

x86 stable

[Comment 9 Agostino Sarubbo 2013-07-21 15:36:26 UTC]

alpha stable

[Comment 10 Agostino Sarubbo 2013-07-21 15:39:21 UTC]

ia64 stable

[Comment 11 Agostino Sarubbo 2013-07-21 16:07:02 UTC]

ppc64 stable

[Comment 12 Agostino Sarubbo 2013-07-21 17:23:53 UTC]

ppc stable

[Comment 13 Agostino Sarubbo 2013-07-21 17:36:22 UTC]

arm stable

[Comment 14 Agostino Sarubbo 2013-07-21 17:41:10 UTC]

sh stable

[Comment 15 Agostino Sarubbo 2013-07-22 08:54:58 UTC]

sparc stable

[Comment 16 Agostino Sarubbo 2013-08-06 12:36:19 UTC]

s390 stable

[Comment 17 Chris Reffett (RETIRED) 2013-08-24 01:24:22 UTC]

GLSA request filed.

[Comment 18 Chris Reffett (RETIRED) 2013-09-01 20:38:13 UTC]

GLSA sent. @maintainers: cleanup please.

[Comment 19 Eray Aslan 2013-09-02 05:54:01 UTC]

sparc still needs to stabilize =dev-libs/cyrus-sasl-2.1.23-r7.

[Comment 20 Agostino Sarubbo 2013-09-14 10:41:17 UTC]

sparc stable

[Comment 21 Sean Amoss (RETIRED) 2013-09-14 15:10:29 UTC]

This issue was resolved and addressed in
 GLSA 201309-01 at http://security.gentoo.org/glsa/glsa-201309-01.xml
by GLSA coordinator Chris Reffett (creffett).