CVE-2014-8182: High severity openldap OpenLDAP vulnerability

Created attachment 893821 [details] proposed fix

Description of problem:

The nss-pam-ldapd daemon nslcd can be configured to find ldap servers via SRV lookups on a domain. With this configuration, a crash seen when starting nslcd can be caused by a number of specific SRV records presented to ldapdomain2hostlist(). The records are a set of 5+ SRV records for ldap.tcp, all with a 5-digit port number, i.e. 12345.

[root@auto1 ~]# dig SRV ldap.tcp.rodan.local | grep ldap ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el65.1 <<>> SRV ldap.tcp.rodan.local ;ldap.tcp.rodan.local. IN SRV ldap.tcp.rodan.local. 3600 IN SRV 1 5 15001 activedirectory2.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 1 5 15001 activedirectory3.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 1 5 15001 activedirectory4.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 0 5 15001 ads.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 0 5 15001 ads2.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 0 5 15001 ads3.rodan.local. ldap.tcp.rodan.local. 3600 IN SRV 1 5 15001 activedirectory.rodan.local.

On startup this crash happens most of the time, and can appear differently:

[root@auto1 ~]# nslcd -d nslcd: DEBUG: query rodan.local for SRV records glibc detected nslcd: realloc(): invalid next size: 0x0000000001e29480 ======= Backtrace: ========= /lib64/libc.so.6(+0x76166)[0x7fda91c7a166] /lib64/libc.so.6(+0x7bc17)[0x7fda91c7fc17] /lib64/libc.so.6(realloc+0xe5)[0x7fda91c7fdd5] /lib64/liblber-2.4.so.2(bermemreallocx+0x2a)[0x7fda919fd87a] /lib64/libldapr-2.4.so.2(ldapdomain2hostlist+0x423)[0x7fda92400f33] nslcd[0x407fb1] nslcd[0x408c0e] nslcd[0x40a21d] nslcd[0x403a75] /lib64/libc.so.6(libcstartmain+0xfd)[0x7fda91c22d1d] nslcd[0x402d39] ======= Memory map: ======== 00400000-0041d000 r-xp 00000000 fd:00 405486 /usr/sbin/nslcd 0061d000-0061e000 rw-p 0001d000 fd:00 405486 /usr/sbin/nslcd 01e28000-01e49000 rw-p 00000000 00:00 0 [heap] 7fda8ed94000-7fda8ee05000 r-xp 00000000 fd:00 261638 /lib64/libfreebl3.so ... [root@auto1 ~]# nslcd -d nslcd: DEBUG: query rodan.local for SRV records glibc detected nslcd: realloc(): invalid next size: 0x00000000023b3480 glibc detected nslcd: malloc(): memory corruption: 0x00000000023b34f0 ^C [root@auto1 ~]# nslcd -d nslcd: DEBUG: query rodan.local for SRV records glibc detected nslcd: realloc(): invalid next size: 0x00000000020bd480 glibc detected nslcd: malloc(): memory corruption: 0x00000000020bd4f0 ^C [root@auto1 ~]# nslcd -d nslcd: DEBUG: query rodan.local for SRV records nslcd: DEBUG: addurisfromdns(): found uri: ldap://activedirectory4.rodan.local:15001 nslcd: DEBUG: adduri(ldap://activedirectory4.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://activedirectory.rodan.local:15001 nslcd: DEBUG: adduri(ldap://activedirectory.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://activedirectory3.rodan.local:15001 nslcd: DEBUG: adduri(ldap://activedirectory3.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://activedirectory2.rodan.local:15001 nslcd: DEBUG: adduri(ldap://activedirectory2.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://ads.rodan.local:15001 nslcd: DEBUG: adduri(ldap://ads.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://ads2.rodan.local:15001 nslcd: DEBUG: adduri(ldap://ads2.rodan.local:15001) nslcd: DEBUG: addurisfromdns(): found uri: ldap://ads3.rodan.local:15001

The crash is related to the maximum length of a port specified in the SRV record. Any 4 digit or less ports did not crash with the same entries, so I suspected that in ldapdomain2hostlist(), doing STRLENOF(":65355") with the 5 digit port ends up missing a byte. It also only starts to show up when there are 5 or more entries in the host list, as it appears that the sprintf at the end of the hostentcount loop needs to be called enough times for this to corrupt the hostlist array. With a larger number of entries the crash would probably have a greater chance of happening.

I'm attaching a patch that changes STRLENOF to sizeof, to account for the proper length needed in the buffer for a max length port. With the patch I tested multiple restarts of nslcd against the records and I wasn't able to reproduce the crash.

I think this bug should be evaluated as a possible CVE. In the event of DNS hijacking/spoofing, a malicious nameserver presenting these specific SRV records may be able to cause a DoS to ldap services that utilize ldapdomain2hostlist().

Version-Release number of selected component (if applicable): openldap-2.4.23-34.el65.1

How reproducible: 1. Create SRV records in DNS as specified above 2. Configure nslcd to do SRV lookups to locate an ldap server (in /etc/nslcd.conf, set 'uri:DNS:domain') 3. Start nslcd in foreground debug mode (nslcd -d)

— Red Hat