RedHat has issued an advisory on March 13: https://rhn.redhat.com/errata/RHSA-2014-0292.html The upstream patch to fix the issue is linked in the RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1074845 Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOO, MGA3TOO
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) => thomasVersion: Cauldron => 4Whiteboard: 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) => davidwhodginsWhiteboard: 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
Whiteboard: MGA3TOO feedback => MGA3TOO
Whiteboard: MGA3TOO => MGA3TOO advisory
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_updateWhiteboard: 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-okCC: (none) => sysadmin-bugs
http://advisories.mageia.org/MGASA-2014-0145.html
Status: ASSIGNED => RESOLVEDCC: (none) => pterjanResolution: (none) => FIXED