[Pkg-openldap-devel] [SRM] Security fixes and possible database corruption

[Matthijs Möhlmann]

Hello SRM (Stable Release Manager),

According to bug #617606 there are currently 2 CVE's open.
CVE-2011-1024:
chain.c in back-ldap in OpenLDAP 2.4.x before 2.4.24, when a master-slave configuration with a chain overlay and ppolicy_forward_updates (aka authentication-failure forwarding) is used, allows remote authenticated users to bypass external-program authentication by sending an invalid password to a slave server.
Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ldap/chain.c.diff?r1=1.76&r2=1.77&hideattic=1&sortbydate=0
Impact: Low, it is a pretty specific configuration.

CVE-2011-1025:
bind.cpp in back-ndb in OpenLDAP 2.4.x before 2.4.24 does not require authentication for the root Distinguished Name (DN), which allows remote attackers to bypass intended access restrictions via an arbitrary password.
Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-ndb/bind.cpp.diff?r1=1.5&r2=1.8
Impact: Low, the ndb backend is disabled in the debian built.

CVE-2011-1081:
modrdn.c in slapd in OpenLDAP 2.4.x before 2.4.24 allows remote attackers to cause a denial of service (daemon crash) via a relative Distinguished Name (DN) modification request (aka MODRDN operation) that contains an empty value for the OldDN field.
Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/modrdn.c.diff?hideattic=1&r1=text&tr1=1.181&r2=text&tr2=1.182&f=c
Impact: High, possibility to remotely crash slapd.

Then we have a possible database corruption (introduced by patch service-operational-before-detach (debian specific))
Fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=service-operational-before-detach;att=1;bug=616164
Above fix is the new patch for service-operational-before-detach.

I would like to fix the above bugs and have it uploaded to squeeze. Am I allowed to fix these
issues for squeeze? And should I upload these through stable-proposed-updates after you
reviewed the debdiff of course?

Regards,

Matthijs Möhlmann