Bug 676876 (CVE-2011-0704)

Summary:	CVE-2011-0704 389: replica crashes due to empty modify request when built with mozldap
Product:	[Other] Security Response	Reporter:	Vincent Danen <vdanen>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	rmeggins, security-response-team
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-04-19 09:25:12 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	675320, 679542
Bug Blocks:

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>
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