| Summary: | <dev-libs/cyrus-sasl-{2.1.23-r7,2.1.26-r3}: Null pointer deference (CVE-2013-4122) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | net-mail+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2013/07/12/3 | ||
| Whiteboard: | A3 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 476034 | ||
@security: Please stabilize =dev-libs/cyrus-sasl-2.1.23-r7 =dev-libs/cyrus-sasl-2.1.26-r3 Thank you. (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? 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! Click [Add arches:]. :) And please please put the atoms on separate lines (from each other and from the rest of the blurb). > 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. Stable for HPPA. amd64 stable x86 stable alpha stable ia64 stable ppc64 stable ppc stable arm stable sh stable sparc stable s390 stable GLSA request filed. GLSA sent. @maintainers: cleanup please. sparc still needs to stabilize =dev-libs/cyrus-sasl-2.1.23-r7. sparc stable 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). |
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.