-------------------------------------------------------------------------- CONECTIVA LINUX SECURITY ANNOUNCEMENT -------------------------------------------------------------------------- PACKAGE : openldap SUMMARY : Denial of Service and other (non-security) fixes DATE : 2003-07-04 19:34:00 ID : CLA-2003:685 RELEVANT RELEASES : 9 ------------------------------------------------------------------------- DESCRIPTION OpenLDAP[1] is an LDAPv2 and LDAPv3 server available for several platforms. This update addresses the following issues in the OpenLDAP package shipped with Conectiva Linux 9: 1) Denial of Service vulnerability[2] A failed password extended operation (password EXOP) can cause openldap to, if using the back-ldbm backend, attempt to free memory which was never allocated, resulting in a segfault. The back-bdb backend, on the other hand, has a memory leak in the same code. Both conditions can be triggered remotely. 2) Crypt and md5 hash support[3] The OpenLDAP packages shipped with Conectiva Linux 9 do not have support for crypt and md5 password hashes. As a result, users migrated to LDAP from system password files will not be able to authenticate against the directory using simple binds. 3) One shot replication mode does not work[4] The slurpd program shipped with OpenLDAP is responsible for replicating data from a master OpenLDAP server to slave servers. It has a replication mode called "one shot" which takes a replication log file and attempts to replicate all changes to the specified slaves and then exits. This mode was not working in openldap-2.1.16, which is the version originally shipped with Conectiva Linux 9. This announcement updates OpenLDAP for Conectiva Linux 9 to version 2.1.21, which, besides containing the fixes above and several others, also includes many other improvements in indexes and performance. SOLUTION It is recommended that all OpenLDAP users in Conectiva Linux 9 update their packages. After the upgrade, the slapd service will be automatically restarted if it was already running. REFERENCES 1. http://www.openldap.org/ 2. http://www.openldap.org/its/index.cgi?findid=2390 3. http://bugzilla.conectiva.com.br/show_bug.cgi?id=8283 4. http://bugzilla.conectiva.com.br/show_bug.cgi?id=8577
we need OpenLDAP2.1 in the stable tree to resolve this (and thusly DB4.1).
db4 is nowhere near stable is it?
quite the opposite, I use DB4.1 and OpenLDAP2.1 on production servers. It's just that some other packages don't always treat DB4.[01] correctly. See the list of dependancy bugs for http://bugs.gentoo.org/show_bug.cgi?id=23571 thats to release db4.1
Given the dependency is now satisfied, it may be a moot point for this time, but would it not be feasible to mark the package stable, and just leave its dependency unstable? That way, the correct impression would be conveyed.
repoman doesn't allow that. emerge would complain about being unable to satisfy dependancies. try it yourself, it's a good self-protection system. however I am going to mail the -dev list and see about moving forward on 4.1
db-4.1 has been marked stable, so that should be no impediment to marking a new openldap stable
2.1.26 is in stable now. our 2.0* tree was the only stable stuff before, and it's definetly affected by this bug. i haven't deleted the 2.0 ebuilds now, but i will once the GLSA is ready. security folks: what should be done on the GLSA now? it's item #1 from the CLA announcement.
Would someone in ppc test 2.1.26? Thanks.
PPC -- plztest.
As openldap-2.1.27-r1 also run on my system, I made this one stable. I guess there are only very few openldap-users on ppc ;-)
Forgot to remove ppc@ from Cc.
I'll start drafting a GLSA for this.
Draft GLSA submitted for review. mips, please test and stabilize. Thanks in advance.
GLSA 200403-12.
We have an error here (thanks to Stuart Moore for reporting it) : 2.1.13 has been released Mon, 24 Feb 2003 2.1.16 has been released Fri, 14 Mar 2003 The fix to passwd.c was committed on their CVS Sat, 22 Mar 2003 2.1.17 has been released Fri, 04 Apr 2003 Fix list for 2.1.17 includes our #2390 bug : ------------------------ OpenLDAP 2.1.17 Release Fixed libldap_r thread pool context bug (ITS#2404) Fixed libldap T.61 convert bug (ITS#2388) Fixed libldap h_errno bug Fixed slapd cn=# bug (ITS#2387) Fixed slapd naming violation error checks Fixed slapd modify password uninit free bug (ITS#2390) Fixed slapd request flooding bug (ITS#2389) Fixed slurpd one shot mode (ITS#2385) Fixed slurpd core dump on exit (ITS#2363) Fixed slapadd oidm destroy bug (ITS#2409) Fixed clients critical argument handling Updated clients password file support Added slappasswd password file support Removed lint (ITS#2382) Build Environment Updated versioning system Added LDAP cache shell-only routines Documentation Updated slurpd(8) -u usage Misc man page updates ---------------------------- It's not critical since (I think) no stable version was released between 2.1.12 and 2.1.26. -K
2.0.23 was marked as stable at one point--but I don't think that's a problem--and 2.0.18 was in CVS but is old enough that it doesn't have a KEYWORDS variable. It was hard to tell, as they didn't have any version numbers in their bug, but it looked as if the patch was against their 2.0.12 code. Maybe I should check the source next time ... What needs to be done about this?
Any objections if any ebuilds older than 2.1.26 are removed?
The GLSA was incorrect, but it's highly doubtful that anyone would be adversely affected by this. Looking at viewcvs, it appears that there was never any versions between 2.1.12 and 2.1.17. So, when we told our users to do "emerge ">=net-nds/openldap-2.1.13"" to fix the vulnerability, they would have had to (at least) install version 2.1.18 which does, in fact, contain the fix. So, I recommend we update the XML file on the web site, bump the revision number on the GLSA and re-close this issue.
Created attachment 28744 [details, diff] glsa-200403-12.xml.diff Patch to fix the GLSA. Can I go ahead and commit this?
The patch is OK for me. I think you should go ahead and commit it (and reclose the bug). -K
OK, patch is committed.