Bug 676876 - (CVE-2011-0704) CVE-2011-0704 389: replica crashes due to empty modify request when built with mozldap
CVE-2011-0704 389: replica crashes due to empty modify request when built wit...
Status: CLOSED CURRENTRELEASE
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20110215,reported=20110204,sou...
: Security
Depends On: 675320 679542
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-11 11:47 EST by Vincent Danen
Modified: 2015-08-19 05:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-19 05:25:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2011-02-11 11:47:02 EST
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.
Comment 1 Vincent Danen 2011-02-11 11:48:21 EST
Acknowledgements:

Red Hat would like to thank Andrew Kerr for reporting this issue.

Statement:

Not vulnerable. This issue did not affect Red Hat Directory Server 8 packages.
Comment 2 Rich Megginson 2011-02-11 13:10:00 EST
Yes, the description looks good.  Thanks!
Comment 3 Rich Megginson 2011-02-22 14:49:06 EST
To ssh://git.fedorahosted.org/git/389/ds.git
   a123b54..1980427  master -> master
commit 1980427b8c78e79982c056ac270c6c3b11188830
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Wed Feb 9 14:54:29 2011 -0700
    Reviewed by: nkinder, nhosoi (Thanks!)
    Branch: master
    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
allows
    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
To ssh://git.fedorahosted.org/git/389/ds.git
   5d4895c..a33cb58  389-ds-base-1.2.8 -> 389-ds-base-1.2.8
Comment 4 Tomas Hoger 2011-04-19 05:25:12 EDT
(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:
http://git.fedorahosted.org/git/?p=389/ds.git;a=commitdiff;h=6160200187b5b5f7ee662762b997c5c55401fe77

(In reply to comment #3)
> To ssh://git.fedorahosted.org/git/389/ds.git
>    a123b54..1980427  master -> master
> commit 1980427b8c78e79982c056ac270c6c3b11188830

http://git.fedorahosted.org/git/?p=389/ds.git;a=commitdiff;h=1980427b8c78e79982c056ac270c6c3b11188830

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