Bug 15232 - openldap new security issue CVE-2015-1545
Summary: openldap new security issue CVE-2015-1545
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/638442/
Whiteboard: has_procedure advisory MGA4-64-OK MGA...
Keywords: validated_update
Depends on:
Blocks:
 
Reported: 2015-02-08 02:03 CET by David Walser
Modified: 2015-04-10 00:55 CEST (History)
4 users (show)

See Also:
Source RPM: openldap-2.4.38-1.1.mga4.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2015-02-08 02:03:44 CET
CVEs have been assigned for two DoS issues fixed upstream in openldap:
http://openwall.com/lists/oss-security/2015/02/07/3

The second issue (CVE-2015-1546) only affects the version in Cauldron.

Patched packages uploaded for Mageia 4 and Cauldron.

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

Updated openldap packages fix security vulnerability:

The deref overlay in slapd 2.4.13 through 2.4.40 dereferences a NULL pointer
when a search request includes the Deref control with an empty list of
attributes to return (missing input validation). This allows a remote
unauthenticated client to crash the LDAP server (CVE-2015-1545).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1545
http://openwall.com/lists/oss-security/2015/02/07/3
========================

Updated packages in core/updates_testing:
========================
openldap-2.4.38-1.2.mga4
openldap-servers-2.4.38-1.2.mga4
openldap-servers-devel-2.4.38-1.2.mga4
openldap-clients-2.4.38-1.2.mga4
libldap2.4_2-2.4.38-1.2.mga4
libldap2.4_2-devel-2.4.38-1.2.mga4
libldap2.4_2-static-devel-2.4.38-1.2.mga4
openldap-back_sql-2.4.38-1.2.mga4
openldap-back_bdb-2.4.38-1.2.mga4
openldap-back_mdb-2.4.38-1.2.mga4
openldap-doc-2.4.38-1.2.mga4
openldap-tests-2.4.38-1.2.mga4
openldap-testprogs-2.4.38-1.2.mga4

from openldap-2.4.38-1.2.mga4.src.rpm

Reproducible: 

Steps to Reproduce:
Comment 1 David Walser 2015-02-08 02:05:06 CET
Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=6527#c8

also, there's a PoC for this issue in the bugs referenced in the oss-security message.  It says to run an ldapsearch command against the LDAP server with -E deref=member: in the arguments.

Whiteboard: (none) => has_procedure

Comment 2 David Walser 2015-02-08 02:29:42 CET
Hmm, Mageia 4 build failed in the test suite:
http://pkgsubmit.mageia.org/uploads/failure/4/core/updates_testing/20150208005436.luigiwalser.valstar.19461/log/openldap-2.4.38-1.2.mga4/build.0.20150208011239.log

CC: (none) => qa-bugs
Assignee: qa-bugs => bgmilne

Comment 3 David Walser 2015-02-08 04:04:02 CET
Cauldron build has failed too:
http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20150208005133.luigiwalser.valstar.19049/log/openldap-2.4.40-3.mga5/build.0.20150208005204.log

I guess the upstream commit broke ldapsearch.  I guess they'll fix it eventually.

Version: 4 => Cauldron
Whiteboard: has_procedure => MGA4TOO has_procedure

Comment 4 Oden Eriksson 2015-02-09 16:23:25 CET
FYI. the tests pass on openldap-2.4.33 (mbs1).

CC: (none) => oe

Comment 5 David Walser 2015-03-27 19:11:47 CET
Mandriva has issued an advisory for this today (March 27):
http://www.mandriva.com/en/support/security/advisories/mbs1/MDVSA-2015%3A074/

Whiteboard: MGA4TOO has_procedure => MGA5TOO MGA4TOO has_procedure

David Walser 2015-03-30 15:26:42 CEST

URL: (none) => http://lwn.net/Vulnerabilities/638442/

Comment 6 David Walser 2015-04-06 00:39:47 CEST
Assigning to QA finally.  See Comment 0 and Comment 1.

Version: Cauldron => 4
Assignee: bgmilne => qa-bugs
Whiteboard: MGA5TOO MGA4TOO has_procedure => has_procedure

Comment 7 claire robinson 2015-04-08 18:11:16 CEST
Testing mga4 64

Some issues.


Installing
----------
# urpmi openldap openldap-servers openldap-clients lib64ldap2.4_2 openldap-back_mdb openldap-back_sql openldap-back_bdb openldap-doc openldap-tests openldap-testprogs

3/9: openldap-servers      #########
Usage: service -[Rfshv] SERVICE ARGUMENTS
        -f|--full-restart:      Do a fullrestart of the service.
        -R|--full-restart-all:  Do a fullrestart of all running services.
        -s|--status-all:        Print a status of all services.
        --ignore-dependencies:  Do not start required systemd services
        --skip-redirect:        Do not redirect to systemd
        -d|--debug:             Launch with debug.
        -h|--help:              This help.



Updating
--------
3/10: openldap-back_bdb     ##########
Using /etc/openldap/slapd.conf as configuration for %pre servers
Stopping slapd.service via systemd and recovering via ldap-check
/var/tmp/rpm-tmp.ByVOBF: line 26: /usr/share/openldap/scripts/ldap-check: No such file or directory


Starting
--------
# systemctl start slapd.service
Job for slapd.service failed. See 'systemctl status slapd.service' and 'journalctl -xn' for details.

# systemctl status slapd.service
slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled)
   Active: failed (Result: exit-code) since Wed 2015-04-08 16:56:49 BST; 5s ago
  Process: 560 ExecStart=/usr/sbin/slapd -u ${LDAP_USER} -g ${LDAP_GROUP} -h ${SLAPDURLLIST} -l ${SLAPDSYSLOGLOCALUSER} (code=exited, status=1/FAILURE)
  Process: 541 ExecStartPre=/usr/share/openldap/scripts/ldap-config check (code=exited, status=0/SUCCESS)

  ldap-config[541]: slaptest: bad configuration file!
  slapd[560]: @(#) $OpenLDAP: slapd 2.4.38 (Apr  4 2015 12:38:44) $
                                         iurt@ecosse.mageia.org:/home/iurt/rpmbuild/BUILD/openldap-2.4.38/servers/slapd
  slapd[560]: Unrecognized database type (bdb)
  slapd[560]: /etc/openldap/slapd.conf: line 107: <database> failed init (bdb)



Uninstalling
------------
removing package openldap-servers-2.4.38-1.2.mga4.x86_64
      6/9: removing openldap-servers-2.4.38-1.2.mga4.x86_64
#########warning: /etc/sysconfig/slapd saved as /etc/sysconfig/slapd.rpmsave
#########warning: file /etc/rc.d/init.d/slapd: remove failed: No such file or directory
#####
Usage: service -[Rfshv] SERVICE ARGUMENTS
        -f|--full-restart:      Do a fullrestart of the service.
        -R|--full-restart-all:  Do a fullrestart of all running services.
        -s|--status-all:        Print a status of all services.
        --ignore-dependencies:  Do not start required systemd services
        --skip-redirect:        Do not redirect to systemd
        -d|--debug:             Launch with debug.
        -h|--help:              This help.
Comment 8 claire robinson 2015-04-08 18:33:51 CEST
Testing as below..

# cd /usr/share/openldap/tests/
# ./run all > ldaptest
# grep -e ">>>>>" ldaptest

It takes a number of minutes (15ish) to complete and often appears to have become stuck, so patience is required.

Don't forget to clean up..

# rm ldaptest 
rm: remove regular file âldaptestâ? y

All self tests succeed so the only issues are the ones in comment 7.


# grep -e ">>>>>" ldaptest
>>>>> Executing all LDAP tests for bdb
>>>>> Starting test000-rootdse for bdb...
>>>>> Test succeeded
>>>>> test000-rootdse completed OK for bdb.
>>>>> Starting test001-slapadd for bdb...
>>>>> Test succeeded
>>>>> test001-slapadd completed OK for bdb.
>>>>> Starting test002-populate for bdb...
>>>>> Test succeeded
>>>>> test002-populate completed OK for bdb.
>>>>> Starting test003-search for bdb...
>>>>> Test succeeded
>>>>> test003-search completed OK for bdb.
>>>>> Starting test004-modify for bdb...
>>>>> Test succeeded
>>>>> test004-modify completed OK for bdb.
>>>>> Starting test005-modrdn for bdb...
>>>>> Test succeeded
>>>>> test005-modrdn completed OK for bdb.
>>>>> Starting test006-acls for bdb...
>>>>> Test succeeded
>>>>> test006-acls completed OK for bdb.
>>>>> Starting test008-concurrency for bdb...
>>>>> Test succeeded
>>>>> test008-concurrency completed OK for bdb.
>>>>> Starting test009-referral for bdb...
>>>>> Test succeeded
>>>>> test009-referral completed OK for bdb.
>>>>> Starting test010-passwd for bdb...
>>>>> Test succeeded
>>>>> test010-passwd completed OK for bdb.
>>>>> Starting test011-glue-slapadd for bdb...
>>>>> Test succeeded
>>>>> test011-glue-slapadd completed OK for bdb.
>>>>> Starting test012-glue-populate for bdb...
>>>>> Test succeeded
>>>>> test012-glue-populate completed OK for bdb.
>>>>> Starting test013-language for bdb...
>>>>> Test succeeded
>>>>> test013-language completed OK for bdb.
>>>>> Starting test014-whoami for bdb...
>>>>> Test succeeded
>>>>> test014-whoami completed OK for bdb.
>>>>> Starting test015-xsearch for bdb...
>>>>> Test succeeded
>>>>> test015-xsearch completed OK for bdb.
>>>>> Starting test016-subref for bdb...
>>>>> Test succeeded
>>>>> test016-subref completed OK for bdb.
>>>>> Starting test017-syncreplication-refresh for bdb...
>>>>> Test succeeded
>>>>> test017-syncreplication-refresh completed OK for bdb.
>>>>> Starting test018-syncreplication-persist for bdb...
>>>>> Test succeeded
>>>>> test018-syncreplication-persist completed OK for bdb.
>>>>> Starting test019-syncreplication-cascade for bdb...
>>>>> Test succeeded
>>>>> test019-syncreplication-cascade completed OK for bdb.
>>>>> Starting test020-proxycache for bdb...
>>>>> Test succeeded
>>>>> test020-proxycache completed OK for bdb.
>>>>> Starting test021-certificate for bdb...
>>>>> Test succeeded
>>>>> test021-certificate completed OK for bdb.
>>>>> Starting test022-ppolicy for bdb...
>>>>> Test succeeded
>>>>> test022-ppolicy completed OK for bdb.
>>>>> Starting test023-refint for bdb...
>>>>> Test succeeded
>>>>> test023-refint completed OK for bdb.
>>>>> Starting test024-unique for bdb...
>>>>> Test succeeded
>>>>> test024-unique completed OK for bdb.
>>>>> Starting test025-limits for bdb...
>>>>> Test succeeded
>>>>> test025-limits completed OK for bdb.
>>>>> Starting test026-dn for bdb...
>>>>> Test succeeded
>>>>> test026-dn completed OK for bdb.
>>>>> Starting test027-emptydn for bdb...
>>>>> Test succeeded
>>>>> test027-emptydn completed OK for bdb.
>>>>> Starting test028-idassert for bdb...
>>>>> Test succeeded
>>>>> test028-idassert completed OK for bdb.
>>>>> Starting test029-ldapglue for bdb...
>>>>> Test succeeded
>>>>> test029-ldapglue completed OK for bdb.
>>>>> Starting test030-relay for bdb...
>>>>> waiting for things to exit
>>>>> waiting for things to exit
>>>>> Test succeeded
>>>>> test030-relay completed OK for bdb.
>>>>> Starting test031-component-filter for bdb...
>>>>> test031-component-filter completed OK for bdb.
>>>>> Starting test032-chain for bdb...
>>>>> Test succeeded
>>>>> test032-chain completed OK for bdb.
>>>>> Starting test033-glue-syncrepl for bdb...
>>>>> Test succeeded
>>>>> test033-glue-syncrepl completed OK for bdb.
>>>>> Starting test034-translucent for bdb...
>>>>> Test succeeded
>>>>> test034-translucent completed OK for bdb.
>>>>> Starting test035-meta for bdb...
>>>>> Test succeeded
>>>>> test035-meta completed OK for bdb.
>>>>> Starting test036-meta-concurrency for bdb...
>>>>> Test succeeded
>>>>> test036-meta-concurrency completed OK for bdb.
>>>>> Starting test037-manage for bdb...
>>>>> Test succeeded
>>>>> test037-manage completed OK for bdb.
>>>>> Starting test038-retcode for bdb...
>>>>> Test succeeded
>>>>> test038-retcode completed OK for bdb.
>>>>> Starting test039-glue-ldap-concurrency for bdb...
>>>>> Test succeeded
>>>>> test039-glue-ldap-concurrency completed OK for bdb.
>>>>> Starting test040-subtree-rename for bdb...
>>>>> test040-subtree-rename completed OK for bdb.
>>>>> Starting test041-aci for bdb...
>>>>> Test succeeded
>>>>> test041-aci completed OK for bdb.
>>>>> Starting test042-valsort for bdb...
>>>>> Test succeeded
>>>>> test042-valsort completed OK for bdb.
>>>>> Starting test043-delta-syncrepl for bdb...
>>>>> Test succeeded
>>>>> test043-delta-syncrepl completed OK for bdb.
>>>>> Starting test044-dynlist for bdb...
>>>>> Test succeeded
>>>>> test044-dynlist completed OK for bdb.
>>>>> Starting test045-syncreplication-proxied for bdb...
>>>>> Test succeeded
>>>>> test045-syncreplication-proxied completed OK for bdb.
>>>>> Starting test046-dds for bdb...
>>>>> Test succeeded
>>>>> test046-dds completed OK for bdb.
>>>>> Starting test047-ldap for bdb...
>>>>> Test succeeded
>>>>> test047-ldap completed OK for bdb.
>>>>> Starting test048-syncrepl-multiproxy for bdb...
>>>>> Test succeeded
>>>>> test048-syncrepl-multiproxy completed OK for bdb.
>>>>> Starting test050-syncrepl-multimaster for bdb...
>>>>> Test succeeded
>>>>> test050-syncrepl-multimaster completed OK for bdb.
>>>>> Starting test051-config-undo for bdb...
>>>>> Test succeeded
>>>>> test051-config-undo completed OK for bdb.
>>>>> Starting test052-memberof for bdb...
>>>>> Test succeeded
>>>>> test052-memberof completed OK for bdb.
>>>>> Starting test054-syncreplication-parallel-load for bdb...
>>>>> Test succeeded
>>>>> test054-syncreplication-parallel-load completed OK for bdb.
>>>>> Starting test055-valregex for bdb...
>>>>> Test succeeded
>>>>> test055-valregex completed OK for bdb.
>>>>> Starting test056-monitor for bdb...
>>>>> Test succeeded
>>>>> test056-monitor completed OK for bdb.
>>>>> Starting test057-memberof-refint for bdb...
>>>>> test057-memberof-refint completed OK for bdb.
>>>>> Starting test058-syncrepl-asymmetric for bdb...
>>>>>> Exiting with a false success status for now
>>>>> test058-syncrepl-asymmetric completed OK for bdb.
>>>>> Starting test059-slave-config for bdb...
>>>>> Test succeeded
>>>>> test059-slave-config completed OK for bdb.
>>>>> Starting test060-mt-hot for bdb...
>>>>> Test succeeded
>>>>> test060-mt-hot completed OK for bdb.
>>>>> Starting test061-syncreplication-initiation for bdb...
>>>>> Test succeeded
>>>>> test061-syncreplication-initiation completed OK for bdb.
>>>>> Starting test063-delta-multimaster for bdb...
>>>>> Test succeeded
>>>>> test063-delta-multimaster completed OK for bdb.
>>>>> Starting test064-constraint for bdb...
>>>>> Test succeeded
>>>>> test064-constraint completed OK for bdb.

Whiteboard: has_procedure => has_procedure feedback

Comment 9 David Walser 2015-04-08 18:38:28 CEST
The uninstalling output is an rpm-helper issue and has been reported several times before.  Hopefully we'll do something about it someday.

The unrecognized database type bdb is a major issue as that's the default database type used by our package.  I used to run the Mandrake/Mandriva/Mageia openldap-servers server for years at home until the little Foxconn systems I was using for my home server at the time got killed by a kernel update in Mageia 3, so I haven't run it on Mageia 4, other than a quick test shortly before the release when it did work fine.

I'm wondering if your issue is because the back_bdb package didn't get installed correctly because of that scriplet error.  Colin fixed it in Cauldron in October but didn't fix it in Mageia 4 SVN :o(

r737858 | colin | 2014-10-10 09:58:12 -0400 (Fri, 10 Oct 2014) | 1 line

Fix ldap-check vs ldap-config typo


I've backported the fix and just pushed a rebuild:
openldap-2.4.38-1.3.mga4.src.rpm

Whiteboard: has_procedure feedback => has_procedure

Comment 10 David Walser 2015-04-08 18:40:54 CEST
Just a note that once it's installed OK it should work fine since it does run a full test suite at build time, so it should be functional.

Other than that, there are certainly long(and I do mean long)-standing packaging issues in this package.  Over the years that I used it, doing a distro upgrade would break it about half the time and I'd have to recreate my LDAP database from the LDIFs.
Comment 11 claire robinson 2015-04-08 18:48:03 CEST
I'll check again tomorrow. 

Mageia servers are likely to use this package at some point now too, if that's any inspiration to anybody.
Comment 12 David Walser 2015-04-08 18:55:53 CEST
We should probably re-do this package from the Fedora one like we already did with apache, php, and bind, to ease future maintenance.  The maintainer of the this package from the Mandrake days technically is supposed to still be in Mageia, but he's been completely unresponsive for the past few years.
Comment 13 claire robinson 2015-04-09 13:35:22 CEST
No better unfortunately..

ExecStartPre=/usr/share/openldap/scripts/ldap-config check (code=exited, status=0/SUCCESS)

  ldap-config[10510]: slaptest: bad configuration file!
  slapd[10531]: @(#) $OpenLDAP: slapd 2.4.38 (Apr  8 2015 19:22:57) $
                                           iurt@rabbit.mageia.org:/home/iurt/rpmbuild/BUILD/openldap-2.4.38/servers/slapd
  slapd[10531]: Unrecognized database type (bdb)
  slapd[10531]: /etc/openldap/slapd.conf: line 107: <database> failed init (bdb)
  slapd[10531]: DIGEST-MD5 common mech free
  slapd[10531]: slapd stopped.
  slapd[10531]: connections_destroy: nothing to destroy.
  systemd[1]: slapd.service: control process exited, code=exited status=1
  systemd[1]: Failed to start OpenLDAP Server Daemon.
  systemd[1]: Unit slapd.service entered failed state.

Whiteboard: has_procedure => has_procedure feedback

Comment 14 claire robinson 2015-04-09 13:44:48 CEST
Tracked it down though, partially. The ldap-config still fails but the server starts ok.

It's missing at least a moduleload line for back_bdb

There is one commented out for back_sql but just adding one in below it does the trick. 

moduleload    back_bdb

So somewhere along the line we've lost the backend setting.


# systemctl start slapd.service 

# systemctl status slapd.service 
slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled)
   Active: active (running) since Thu 2015-04-09 12:38:23 BST; 3s ago
  Process: 14622 ExecStart=/usr/sbin/slapd -u ${LDAP_USER} -g ${LDAP_GROUP} -h ${SLAPDURLLIST} -l ${SLAPDSYSLOGLOCALUSER} (code=exited, status=0/SUCCESS)
  Process: 14601 ExecStartPre=/usr/share/openldap/scripts/ldap-config check (code=exited, status=0/SUCCESS)
 Main PID: 14624 (slapd)
   CGroup: /system.slice/slapd.service
           ââ14624 /usr/sbin/slapd -u ldap -g ldap -h ldap:/// ldapi:/// -l local4

  su[14607]: (to ldap) root on none
  ldap-config[14601]: Checking config file /etc/openldap/slapd.conf: [FAILED]
  ldap-config[14601]: 552664af bdb_db_open: "dc=example,dc=com"
  ldap-config[14601]: 552664af bdb_db_open: database "dc=example,dc=com": db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2).
  ldap-config[14601]: 552664af backend_startup_one (type=bdb, suffix="dc=example,dc=com"): bi_db_open failed! (2)
  ldap-config[14601]: slap_startup failed (test would succeed using the -u switch)
  slapd[14622]: @(#) $OpenLDAP: slapd 2.4.38 (Apr  8 2015 19:22:57) $
                                           iurt@rabbit.mageia.org:/home/iurt/rpmbuild/BUILD/openldap-2.4.38/servers/slapd
  slapd[14624]: slapd starting
  systemd[1]: Started OpenLDAP Server Daemon.
Comment 15 claire robinson 2015-04-09 13:54:06 CEST
This might have something to do with it..

http://svnweb.mageia.org/packages?view=revision&revision=563724
Comment 16 David Walser 2015-04-09 13:56:03 CEST
It looks like this was messed up in the 2.4.38 update during late mga4 development.  That's when the bdb backend was split out into a subpackage.  It has a scriplet to add itself to the config, but it is run as a triggerpostun for some strange reason, so that won't be run when you install it AFAIK.  This package is such a mess :o(  I don't know if there's a safe way to fix it.  I guess anyone already using it would have figured things out and gotten a working config, so we probably shouldn't mess with it now.  BTW, I see comments in the SPEC that bdb is supposed to be deprecated and people should be switching to mdb.

Whiteboard: has_procedure feedback => has_procedure

Comment 17 claire robinson 2015-04-09 13:57:55 CEST
Seems the intent was to initiate a move to mdb instead..

332 	  	 #To aid upgrades for people using bdb or hdb while we prepare for their removal
333 	  	 %if %build_modp_bdb
334 	  	 Requires:       %{name}-back_bdb = %{version}
335 	  	 %endif
336 	  	 #At some point, we may want to suggest back_mdb, which will become the default backend in future
337 	  	 %if %build_modp_mdb
338 	  	 #Suggests:      %{name}-back_mdb = %{version}
339 	  	 %endif
Comment 18 claire robinson 2015-04-09 14:57:12 CEST
Following a quick IRC pow-wow we've agreed that this package is quite complex and obviously needs substantial maintenance which goes beyond what can be accomplished here.

Self tests all pass on i586 and x86_64 with the rebuilt packages, which fix the error when installing openldap-back_bdb package.


Validating. Advisory uploaded.

Please push to 4 updates

Thanks

Keywords: (none) => validated_update
Whiteboard: has_procedure => has_procedure advisory MGA4-64-OK MGA4-32-OK
CC: (none) => sysadmin-bugs

Comment 19 Pascal Terjan 2015-04-10 00:36:34 CEST
Checking SRPMs⦠                      â (4/core/openldap-2.4.38-1.2.mga4) 

Updated advisory to point to 1.3.

CC: (none) => pterjan

Comment 20 Mageia Robot 2015-04-10 00:55:15 CEST
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGASA-2015-0143.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED


Note You need to log in before you can comment on or make changes to this bug.