A CVE has been assigned for a denial of service issue fixed upstream: http://openwall.com/lists/oss-security/2015/09/11/5 Patched packages building for Mageia 4, Mageia 5, and Cauldron. They should be available in a few hours. Advisory: ======================== Updated openldap packages fix security vulnerability: By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call in the ber_get_next() method in a/libraries/liblber/io.c that is hit when decoding tampered BER data (CVE-2015-6908). References: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8240 http://openwall.com/lists/oss-security/2015/09/11/5 ======================== Updated packages in core/updates_testing: ======================== openldap-2.4.38-1.4.mga4 openldap-servers-2.4.38-1.4.mga4 openldap-servers-devel-2.4.38-1.4.mga4 openldap-clients-2.4.38-1.4.mga4 libldap2.4_2-2.4.38-1.4.mga4 libldap2.4_2-devel-2.4.38-1.4.mga4 libldap2.4_2-static-devel-2.4.38-1.4.mga4 openldap-back_sql-2.4.38-1.4.mga4 openldap-back_bdb-2.4.38-1.4.mga4 openldap-back_mdb-2.4.38-1.4.mga4 openldap-doc-2.4.38-1.4.mga4 openldap-tests-2.4.38-1.4.mga4 openldap-testprogs-2.4.38-1.4.mga4 openldap-2.4.40-3.1.mga5 openldap-servers-2.4.40-3.1.mga5 openldap-servers-devel-2.4.40-3.1.mga5 openldap-clients-2.4.40-3.1.mga5 libldap2.4_2-2.4.40-3.1.mga5 libldap2.4_2-devel-2.4.40-3.1.mga5 libldap2.4_2-static-devel-2.4.40-3.1.mga5 openldap-back_sql-2.4.40-3.1.mga5 openldap-back_bdb-2.4.40-3.1.mga5 openldap-back_mdb-2.4.40-3.1.mga5 openldap-doc-2.4.40-3.1.mga5 openldap-tests-2.4.40-3.1.mga5 openldap-testprogs-2.4.40-3.1.mga5 from SRPMS: openldap-2.4.38-1.4.mga4.src.rpm openldap-2.4.40-3.1.mga5.src.rpm Reproducible: Steps to Reproduce:
Testing procedure: https://bugs.mageia.org/show_bug.cgi?id=6527#c8 Also, there's a simple PoC for this issue in the upstream bug in the references.
Whiteboard: (none) => MGA4TOO has_procedure
I forgot that the test suite conflicts if you have more than one going at the same time, so the mga4 build partially failed and I had to submit it again with a higher subrel. The Mageia 4 packages are now: openldap-2.4.38-1.5.mga4 openldap-servers-2.4.38-1.5.mga4 openldap-servers-devel-2.4.38-1.5.mga4 openldap-clients-2.4.38-1.5.mga4 libldap2.4_2-2.4.38-1.5.mga4 libldap2.4_2-devel-2.4.38-1.5.mga4 libldap2.4_2-static-devel-2.4.38-1.5.mga4 openldap-back_sql-2.4.38-1.5.mga4 openldap-back_bdb-2.4.38-1.5.mga4 openldap-back_mdb-2.4.38-1.5.mga4 openldap-doc-2.4.38-1.5.mga4 openldap-tests-2.4.38-1.5.mga4 openldap-testprogs-2.4.38-1.5.mga4 from openldap-2.4.38-1.5.mga4.src.rpm
mga5 x86_64 Installed packages : lib64ldap2.4_2-devel-2.4.40-3.1.mga5 openldap-clients-2.4.40-3.1.mga5 openldap-back_bdb-2.4.40-3.1.mga5 openldap-testprogs-2.4.40-3.1.mga5 openldap-extra-schemas-1.3-17.mga5 openldap-tests-2.4.40-3.1.mga5 openldap-servers-2.4.40-3.1.mga5 lib64ldap2.4_2-2.4.40-3.1.mga5 openldap-2.4.40-3.mga5 Testing procedure https://bugs.mageia.org/show_bug.cgi?id=6527#c8 don't work : there's no ldap.service Trying systemctl start slapd.service : Failed systemctl status slapd.service â slapd.service - OpenLDAP Server Daemon Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled) Active: failed (Result: exit-code) since ven. 2015-09-11 20:44:27 CEST; 6s ago Process: 13179 ExecStart=/usr/sbin/slapd -u ${LDAP_USER} -g ${LDAP_GROUP} -h ${SLAPDURLLIST} -l ${SLAPDSYSLOGLOCALUSER} (code=exited, status=1/FAILURE) Process: 13150 ExecStartPre=/usr/share/openldap/scripts/ldap-config check (code=exited, status=0/SUCCESS) sept. 11 20:44:27 localhost slapd[13179]: @(#) $OpenLDAP: slapd 2.4.40 (Sep 11 2015 15:29:45) $ iurt@ecosse.mageia.org:/home/iurt/rpmbuild/BUILD/openldap-2.4.40/servers/slapd sept. 11 20:44:27 localhost slapd[13179]: Unrecognized database type (bdb) sept. 11 20:44:27 localhost slapd[13179]: /etc/openldap/slapd.conf: line 107: <database> failed init (bdb) sept. 11 20:44:27 localhost slapd[13179]: DIGEST-MD5 common mech free sept. 11 20:44:27 localhost slapd[13179]: slapd stopped. sept. 11 20:44:27 localhost slapd[13179]: connections_destroy: nothing to destroy. sept. 11 20:44:27 localhost systemd[1]: slapd.service: control process exited, code=exited status=1 sept. 11 20:44:27 localhost systemd[1]: Failed to start OpenLDAP Server Daemon. sept. 11 20:44:27 localhost systemd[1]: Unit slapd.service entered failed state. sept. 11 20:44:27 localhost systemd[1]: slapd.service failed. Did i miss something ?
CC: (none) => yann.cantin
(In reply to Yann Cantin from comment #3) > mga5 x86_64 > > Installed packages : > lib64ldap2.4_2-devel-2.4.40-3.1.mga5 > openldap-clients-2.4.40-3.1.mga5 > openldap-back_bdb-2.4.40-3.1.mga5 > openldap-testprogs-2.4.40-3.1.mga5 > openldap-extra-schemas-1.3-17.mga5 > openldap-tests-2.4.40-3.1.mga5 > openldap-servers-2.4.40-3.1.mga5 > lib64ldap2.4_2-2.4.40-3.1.mga5 > openldap-2.4.40-3.mga5 > > Testing procedure https://bugs.mageia.org/show_bug.cgi?id=6527#c8 don't work > : there's no ldap.service > > Trying systemctl start slapd.service : Failed > > systemctl status slapd.service > â slapd.service - OpenLDAP Server Daemon > Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled) > Active: failed (Result: exit-code) since ven. 2015-09-11 20:44:27 CEST; > 6s ago > Process: 13179 ExecStart=/usr/sbin/slapd -u ${LDAP_USER} -g ${LDAP_GROUP} > -h ${SLAPDURLLIST} -l ${SLAPDSYSLOGLOCALUSER} (code=exited, status=1/FAILURE) > Process: 13150 ExecStartPre=/usr/share/openldap/scripts/ldap-config check > (code=exited, status=0/SUCCESS) > > sept. 11 20:44:27 localhost slapd[13179]: @(#) $OpenLDAP: slapd 2.4.40 (Sep > 11 2015 15:29:45) $ > > iurt@ecosse.mageia.org:/home/iurt/rpmbuild/BUILD/openldap-2.4.40/servers/ > slapd > sept. 11 20:44:27 localhost slapd[13179]: Unrecognized database type (bdb) > sept. 11 20:44:27 localhost slapd[13179]: /etc/openldap/slapd.conf: line > 107: <database> failed init (bdb) > sept. 11 20:44:27 localhost slapd[13179]: DIGEST-MD5 common mech free > sept. 11 20:44:27 localhost slapd[13179]: slapd stopped. > sept. 11 20:44:27 localhost slapd[13179]: connections_destroy: nothing to > destroy. > sept. 11 20:44:27 localhost systemd[1]: slapd.service: control process > exited, code=exited status=1 > sept. 11 20:44:27 localhost systemd[1]: Failed to start OpenLDAP Server > Daemon. > sept. 11 20:44:27 localhost systemd[1]: Unit slapd.service entered failed > state. > sept. 11 20:44:27 localhost systemd[1]: slapd.service failed. > > Did i miss something ? No, Claire ran into the same problem in Bug 15232. See the discussion there. You can install the openldap-back_bdb package or try switching to mdb in the config.
mga5 x86_64 : FAILED Added moduleload back_bdb.la in /etc/openldap/slapd.conf - systemctl start slapd.service : OK but systemctl status slapd.service shows : ldap-config[21710]: slap_startup failed (test would succeed using the -u switch) - cd /usr/share/openldap/tests/ ./run all > ldaptest : FAILED Lots of "slapd-bind PID=25534: ldap_sasl_bind_s: Invalid credentials (49)" and finally : ./scripts/test019-syncreplication-cascade: ligne 391 : kill: (26208) - Aucun processus de ce type End of ldaptest : >>>>> Starting test019-syncreplication-cascade for bdb... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=26191) is running... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=26202) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=26208) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=26218) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=26225) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=26234) is running... Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... Performing modify alone on provider... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... ldapsearch failed at R2 slave (32)! >>>>> test019-syncreplication-cascade failed for bdb (exit 32)
The bottom line with this package is, it's known that it has some issues, but it does work once you get it set up, and at build time a test suite runs to ensure that it's still functional, so all we really need to do here is test that it installs/upgrades cleanly and let it go.
Debian has issued an advisory for this on September 12: https://www.debian.org/security/2015/dsa-3356
URL: (none) => http://lwn.net/Vulnerabilities/657321/
Tested using ... $ cat bin/showldap #!/bin/bash myuid="uid=davidwhodgins,ou=People,dc=mageia,dc=org" ldapvi --host ldap.mageia.org -Z --tls allow -D $myuid -b $myuid Testing complete on Mageia 4 and 5. Advisory uploaded. Validating the update.
Keywords: (none) => validated_updateWhiteboard: MGA4TOO has_procedure => MGA4TOO has_procedure MGA4-64-OK MGA5-32-OK advisoryCC: (none) => davidwhodgins, sysadmin-bugs
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0374.html
Status: NEW => RESOLVEDResolution: (none) => FIXED