we will just update Cauldron when it builds.
But as I read it, it will affect mga3 and mga4 too

Status: NEW => ASSIGNED

This bug is now fixed. I didn't do any test. Per upstream, the deleted code wasn't used anyway.

Cauldron doesn't have this bug. The fix was already applied in the source.

mga3 and mga4 have the patch from upstream applied.
The following paackges are now un updates_testing, mageia3 and mageia4:
389-ds-base-1.3.0.9-1.1.mga3.src.rpm
389-ds-base-1.3.0.9-1.1.mga3.x86_64.rpm
389-ds-base-libs-1.3.0.9-1.1.mga3.x86_64.rpm
389-ds-base-devel-1.3.0.9-1.1.mga3.x86_64.rpm
389-ds-base-debuginfo-1.3.0.9-1.1.mga3.x86_64.rpm
and 32 bit

389-ds-base-1.3.2.7-1.1.mga4.src.rpm
389-ds-base-1.3.2.7-1.1.mga4.x86_64.rpm
389-ds-base-libs-1.3.2.7-1.1.mga4.x86_64.rpm
389-ds-base-devel-1.3.2.7-1.1.mga4.x86_64.rpm
389-ds-base-debuginfo-1.3.2.7-1.1.mga4.x86_64.rpm
and 32bit

Assignee: thomas => qa-bugs

Thanks Thomas!

Advisory:
========================

Updated 389-ds-base packages fix security vulnerabilities:

It was discovered that the 389 Directory Server did not properly handle
certain SASL-based authentication mechanisms. A user able to authenticate
to the directory using these SASL mechanisms could connect as any other
directory user, including the administrative Directory Manager account.
This could allow them to modify configuration values, as well as read and
write any data the directory holds (CVE-2014-0132).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0132
https://rhn.redhat.com/errata/RHSA-2014-0292.html
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.3.0.9-1.1.mga3
389-ds-base-libs-1.3.0.9-1.1.mga3
389-ds-base-devel-1.3.0.9-1.1.mga3
389-ds-base-1.3.2.7-1.1.mga4
389-ds-base-libs-1.3.2.7-1.1.mga4
389-ds-base-devel-1.3.2.7-1.1.mga4
389-ds-base-debuginfo-1.3.2.7-1.1.mga4

from SRPMS:
389-ds-base-1.3.0.9-1.1.mga3.src.rpm
389-ds-base-1.3.2.7-1.1.mga4.src.rpm

CC: (none) => thomas
Version: Cauldron => 4
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO

The following packages have bad signatures:            
/var/cache/urpmi/rpms/389-ds-base-1.3.0.9-1.1.mga3.i586.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-devel-1.3.0.9-1.1.mga3.i586.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-libs-1.3.0.9-1.1.mga3.i586.rpm: Missing signature (OK ((none)))

CC: (none) => davidwhodgins
Whiteboard: MGA3TOO => MGA3TOO feedback

Also
/var/cache/urpmi/rpms/389-ds-base-libs-1.3.0.9-1.1.mga3.x86_64.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-libs-1.3.0.9-1.1.mga3.x86_64.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-1.3.2.7-1.1.mga4.i586.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-libs-1.3.2.7-1.1.mga4.i586.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-1.3.2.7-1.1.mga4.x86_64.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-devel-1.3.2.7-1.1.mga4.x86_64.rpm: Missing signature (OK ((none)))
/var/cache/urpmi/rpms/389-ds-base-libs-1.3.2.7-1.1.mga4.x86_64.rpm: Missing signature (OK ((none)))

signed packages are being mirrored out

CC: (none) => tmb

Procedure: https://bugs.mageia.org/show_bug.cgi?id=11720#c7

It needs a properly set hostname to work so it starts with checking the hostname is set to something sane.

Difficult to reproduce the CVE but used madb to confirm the patch has been applied in both mga3 and mga4.

Whiteboard: MGA3TOO advisory => MGA3TOO advisory has_procedure

Testing complete mga3 32

Whiteboard: MGA3TOO advisory has_procedure => MGA3TOO advisory has_procedure mga3-32-ok

Testing complete mga3 64

Whiteboard: MGA3TOO advisory has_procedure mga3-32-ok => MGA3TOO advisory has_procedure mga3-32-ok mga3-64-ok

Trying MGA4 64-bit real hardware.
https://fedorahosted.org/389/ticket/47739 describes the actual fault.
https://fedorahosted.org/389/attachment/ticket/47739/f1 demonstrates it.

Procedure as referenced in Comment 7.
Having chosen Express setup 1, and entered a null Directory Manager DN with real password, it gave:
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 28, in <module>
    import seobject
  File "/usr/lib64/python2.7/site-packages/seobject.py", line 24, in <module>
    import pwd, grp, string, selinux, tempfile, os, re, sys, stat
ImportError: No module named selinux
 Then hung a long time, but eventually said:
Your new DS instance 'freebox' was successfully created.

# systemctl start dirsrv@freebox.service
# netstat -pant | grep 389
tcp        0      0 :::389  :::*     LISTEN      6914/ns-slapd

The O/P from
 ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
was as in the procedure.

Unable to probe deeper without investigating kinit. OK to OK this?

CC: (none) => lewyssmith

Tests ok here Lewis mga4 64

Whiteboard: MGA3TOO advisory has_procedure mga3-32-ok mga3-64-ok => MGA3TOO advisory has_procedure mga3-32-ok mga3-64-ok mga4-64-ok

Testing complete mga4 32

Validating. Advisory previously uploaded.

Could sysadmin please push to 3 & 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: MGA3TOO advisory has_procedure mga3-32-ok mga3-64-ok mga4-64-ok => MGA3TOO advisory has_procedure mga3-32-ok mga3-64-ok mga4-32-ok mga4-64-ok
CC: (none) => sysadmin-bugs

http://advisories.mageia.org/MGASA-2014-0145.html

Status: ASSIGNED => RESOLVED
CC: (none) => pterjan
Resolution: (none) => FIXED