Bug 676876 (CVE-2011-0704) - CVE-2011-0704 389: replica crashes due to empty modify request when built with mozldap
Summary: CVE-2011-0704 389: replica crashes due to empty modify request when built wit...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: CVE-2011-0704
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 675320 679542
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-11 16:47 UTC by Vincent Danen
Modified: 2019-09-29 12:42 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-19 09:25:12 UTC


Attachments (Terms of Use)

Description Vincent Danen 2011-02-11 16:47:02 UTC
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 16:48:21 UTC
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 18:10:00 UTC
Yes, the description looks good.  Thanks!

Comment 3 Rich Megginson 2011-02-22 19:49:06 UTC
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 09:25:12 UTC
(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.