Andrew Kerr reported that a 389 replica would crash when an empty modify request is sent to it. This can only happen if the 389 server is built with mozldap (not OpenLDAP) and the modify operation is replicated or the server set 'cn=config nsslapd-lastmod: off'.
389 on Fedora 14 and later, as well as Red Hat Enterprise Linux 6, use OpenLDAP, not mozldap, and are thus unaffected. This flaw does not affect Red Hat Directory Server 8.2.
This flaw was caused by the fix for bug #305131 which allowed empty modify operations to proceed through the code.
Red Hat would like to thank Andrew Kerr for reporting this issue.
Not vulnerable. This issue did not affect Red Hat Directory Server 8 packages.
Yes, the description looks good. Thanks!
a123b54..1980427 master -> master
Author: Rich Megginson <email@example.com>
Date: Wed Feb 9 14:54:29 2011 -0700
Reviewed by: nkinder, nhosoi (Thanks!)
Fix Description: Check the modifications after lastmod is applied, if any.
If there are still no mods to apply, just return LDAP_SUCCESS to the client
and end the modify request. This makes it so that an empty modify is
allowed, but no further processing is done to avoid code that may not deal
with mods == NULL.
I also found a problem with the way an empty modify was handled. OpenLDAP
does not return an explicit error code if there was a problem reading the
sequence of modify ops, so we have to resort to other checking. This
an empty modify to pass through, when using either mozldap or openldap.
Platforms tested: RHEL5 x86_64, RHEL6 x86_64
Flag Day: no
Doc impact: no
5d4895c..a33cb58 389-ds-base-1.2.8 -> 389-ds-base-1.2.8
(In reply to comment #0)
> This flaw was caused by the fix for bug #305131 which allowed empty modify
> operations to proceed through the code.
Relevant git commit:
(In reply to comment #3)
> To ssh://git.fedorahosted.org/git/389/ds.git
> a123b54..1980427 master -> master
> commit 1980427b8c78e79982c056ac270c6c3b11188830