- openldap-bugs - openldap.org

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 30 Nov '06

30 Nov '06

Aaron Richton wrote: > Actually, this could be it exactly. To my reading, the 0.9.8d tarball > still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses > CRYPTO_set_id_callback. And the most recent thread I see on the matter > ended > (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with > an attitude of "Yeah, if anything, we should make things break more > frequently when there's no callback set." Perhaps we should be adding > one, with a bit of platform awareness through lutil? In the current OpenSSL, the address of errno is tested as well. Since this is always unique per thread, there's really no need to set the id callback any more. The problem with just using CRYPTO_set_id_callback is that it doesn't work on platforms where a thread ID is not an integer (e.g. OS/390). I don't think CRYPTO_set_idptr_callback was available in earlier OpenSSL releases. Too bad they didn't define CRYPTO_set_id_callback correctly, to return the actual type of a thread ID instead of unsigned long. > > On Wed, 29 Nov 2006, Howard Chu wrote: > >> Aaron Richton wrote: >>> I'm on latest 0.9.7 release. I can try and put together a slapd with >>> 0.9.8d, and I guess if we're going to (potentially?) be pointing >>> fingers toward OpenSSL that's a good idea anyway... >> >> Yes, definitely a good idea. The prior releases always used getpid() >> to determine the threadID of the current thread, to decide if locking >> was needed. This is obviously only correct on old systems running >> LinuxThreads, where each thread was actually a separate process. It's >> surprising that it wasn't until recently that we've started seeing >> crashes caused by this 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/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 30 Nov '06

30 Nov '06

Actually, this could be it exactly. To my reading, the 0.9.8d tarball still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses CRYPTO_set_id_callback. And the most recent thread I see on the matter ended (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with an attitude of "Yeah, if anything, we should make things break more frequently when there's no callback set." Perhaps we should be adding one, with a bit of platform awareness through lutil? On Wed, 29 Nov 2006, Howard Chu wrote: > Aaron Richton wrote: >> I'm on latest 0.9.7 release. I can try and put together a slapd with >> 0.9.8d, and I guess if we're going to (potentially?) be pointing fingers >> toward OpenSSL that's a good idea anyway... > > Yes, definitely a good idea. The prior releases always used getpid() to > determine the threadID of the current thread, to decide if locking was > needed. This is obviously only correct on old systems running LinuxThreads, > where each thread was actually a separate process. It's surprising that it > wasn't until recently that we've started seeing crashes caused by this bug.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 29 Nov '06

29 Nov '06

Aaron Richton wrote: > I'm on latest 0.9.7 release. I can try and put together a slapd with > 0.9.8d, and I guess if we're going to (potentially?) be pointing fingers > toward OpenSSL that's a good idea anyway... Yes, definitely a good idea. The prior releases always used getpid() to determine the threadID of the current thread, to decide if locking was needed. This is obviously only correct on old systems running LinuxThreads, where each thread was actually a separate process. It's surprising that it wasn't until recently that we've started seeing crashes caused by this bug. > > On Tue, 28 Nov 2006, Howard Chu wrote: > >> richton(a)nbcs.rutgers.edu wrote: >>> Here's another, although without a malloc debugger: >> >>> What would be good ways to go about figuring out if this is an issue >>> with the SSL library or slapd's usage thereof? >> >> What version of OpenSSL are you using? I've definitely encountered >> locking issues in 0.9.7 and early 0.9.8 releases. Some of those are >> supposed to be fixed in the latest 0.9.8. >> >> -- >> -- 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/ >> > > . > -- -- 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/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 29 Nov '06

29 Nov '06

Here's another, although without a malloc debugger: current thread: t@11 [1] t_delete(0x9e4fa18, 0x80, 0xd7d0bc0, 0xfec3c000, 0x0, 0xedbff3f1), at 0xfebc783c [2] _malloc_unlocked(0x80, 0x0, 0xedbff3e8, 0xfec3c000, 0x4, 0x5), at 0xfebc6ecc [3] malloc(0x80, 0xff000000, 0x0, 0x0, 0x0, 0x0), at 0xfebc6d00 =>[4] default_malloc_ex(num = 128U, file = 0xfefe30b0 "bn_rand.c", line = 134), line 79 in "mem.c" [5] CRYPTO_malloc(num = 128, file = 0xfefe30b0 "bn_rand.c", line = 134), line 304 in "mem.c" [6] bnrand(pseudorand = 0, rnd = 0xa6b753c, bits = 1024, top = -1, bottom = 0), line 134 in "bn_rand.c" [7] BN_rand(rnd = 0xa6b753c, bits = 1024, top = -1, bottom = 0), line 212 in "bn_rand.c" [8] bn_rand_range(pseudo = 0, r = 0xa6b753c, range = 0x368558), line 274 in "bn_rand.c" [9] BN_rand_range(r = 0xa6b753c, range = 0x368558), line 285 in "bn_rand.c" [10] setup_blinding(rsa = 0x368298, ctx = 0xa6b7538), line 308 in "rsa_eay.c" [11] RSA_eay_private_decrypt(flen = 128, from = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", to = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", rsa = 0x368298, padding = 1), line 536 in "rsa_eay.c" [12] RSA_private_decrypt(flen = 128, from = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", to = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", rsa = 0x368298, padding = 1), line 292 in "rsa_lib.c" [13] ssl3_get_client_key_exchange(s = 0xd25c868), line 1454 in "s3_srvr.c" [14] ssl3_accept(s = 0xd25c868), line 448 in "s3_srvr.c" [15] SSL_accept(s = 0xd25c868), line 816 in "ssl_lib.c" [16] ldap_pvt_tls_accept(sb = 0xcc316f8, ctx_arg = 0x31f4e8), line 863 in "tls.c" [17] connection_read(s = 63), line 1337 in "connection.c" [18] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c" What would be good ways to go about figuring out if this is an issue with the SSL library or slapd's usage thereof?

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_3513_4952625.1164743928641 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry folks, it does look like a libdb mismatch. A little bit of poking around found conflicting versions on the system and slapd opening both, and setting up another testbed with 2.3.30 finds the server immune to the NASL test. Sorry to bother you guys, and thanks for the help. Brian ------=_Part_3513_4952625.1164743928641 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry folks, it does look like a libdb mismatch. A little bit of poking around found conflicting versions on the system and slapd opening both, and setting up another testbed with 2.3.30 finds the server immune to the NASL test. Sorry to bother you guys, and thanks for the help. Brian ------=_Part_3513_4952625.1164743928641--

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_3380_11468608.1164742144339 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code. Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped. 1) If I send a SINGLE SPACE to start the data portion, like so: mkbyte(4) + mkbyte(8) + "CRAM-MD5" + mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1) + crap(data:"A", length:1023); the server NEVER crashes, no matter how many times I try it. 2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes) 3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up. Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see: slap_sasl_getdn: conn 10 id= [len=1] If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining "Failure: need authentication name". I'm not sure if this helps or just muddies the issue further. ------=_Part_3380_11468608.1164742144339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code. Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped. 1) If I send a SINGLE SPACE to start the data portion, like so:       mkbyte(4) + mkbyte(8) + "CRAM-MD5" +       mkbyte(4) + mkbyte(0x82) + mkword(0x0400) +       crap(data:" ", length:1) +       crap(data:"A", length:1023); the server NEVER crashes, no matter how many times I try it. 2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes) 3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up. Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see: slap_sasl_getdn: conn 10 id=  [len=1]  If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining  "Failure: need authentication name". I'm not sure if this helps or just muddies the issue further. ------=_Part_3380_11468608.1164742144339--

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_2868_7949219.1164737844232 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Entirely possible (conflicting libdb versions). However, this crash is 100% reproduceable on my system using the Nessus test specifically for the bug at issue here. Nessus script ID is 20939, entitled "OpenLDAP SASL Bind Denial of Service Vulnerability". I actually was going to try to reproduce the problem with a perl script but it seemed more time than it was worth since I had a reliable failure case with the NASL script. I've searched to see if there appears to be a libdb conflict of some sort, and can't find anything, but that may just mean I haven't looked hard enough! I spent some more time poring of the code last night, and nothing jumped out at me. However, as a further data point, I played with the NASL script some to send different data, and I can ONLY get the server to crash if I send spaces. Specifically, the relevant (and hopefully self-documenting) line of NASL script is as follows: mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1024); If 'data:" "' is changed to be 'data:"A"', for example, the server does not crash, and the message in the debug output is what I expect (snipped for brevity). Last line of hex dump follows: 0400: 41 41 41 41 AAAA ber_scanf fmt (}}) ber: ber_dump: buf=0x09ec9330 ptr=0x09ec974f end=0x09ec974f len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=1024 SASL [conn=3] Failure: need authentication name send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-5): bad protocol / cancel: need authentication name" send_ldap_response: msgid=509 tag=97 err=80 ber_flush: 72 bytes to sd 13 Does this help? Brian On 11/27/06, Howard Chu <hyc(a)symas.com> wrote: > > Kurt D. Zeilenga wrote: > > At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: > >> Kurt(a)OpenLDAP.org wrote: > >>> 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? > >> It has a single escaped space. > > > > And that's correct (I was wrong before). A directory string of > > N spaces normalizes to a single space, which must be escaped in > > the DN. > > > > So it does seem like you and Brian are simply not running the > > same code. > > The only difference between my current RE23 tree and 2.3.30 is in > syncprov.c which is obviously not involved here. I would guess Brian's > issue may be libsasl2 related, and no longer something resident in the > OpenLDAP code. (E.g., conflicting libdb versions.) > > -- > -- 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/ > ------=_Part_2868_7949219.1164737844232 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Entirely possible (conflicting libdb versions). However, this crash is 100% reproduceable on my system using the Nessus test specifically for the bug at issue here. Nessus script ID is 20939, entitled "OpenLDAP SASL Bind Denial of Service Vulnerability". I actually was going to try to reproduce the problem with a perl script but it seemed more time than it was worth since I had a reliable failure case with the NASL script. I've searched to see if there appears to be a libdb conflict of some sort, and can't find anything, but that may just mean I haven't looked hard enough! I spent some more time poring of the code last night, and nothing jumped out at me. However, as a further data point, I played with the NASL script some to send different data, and I can ONLY get the server to crash if I send spaces. Specifically, the relevant (and hopefully self-documenting) line of NASL script is as follows: mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1024); If 'data:" "' is changed to be 'data:"A"', for example, the server does not crash, and the message in the debug output is what I expect (snipped for brevity). Last line of hex dump follows:   0400:  41 41 41 41                                        AAAA ber_scanf fmt (}}) ber: ber_dump: buf=0x09ec9330 ptr=0x09ec974f end=0x09ec974f len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=1024 SASL [conn=3] Failure: need authentication name send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-5): bad protocol / cancel: need authentication name" send_ldap_response: msgid=509 tag=97 err=80 ber_flush: 72 bytes to sd 13 Does this help? Brian <div>On 11/27/06, Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Kurt D. Zeilenga wrote: > At 08:06 PM 11/27/2006, <a href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: >> <a href="mailto:Kurt@OpenLDAP.org">Kurt(a)OpenLDAP.org</a> wrote: >>> 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: >>>>  <a href="http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625"> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625</a> >>>> >>>> Suspect a mismatch between what you and Brian are >>>> testing... >>> Howard, is the normalized authcDN in your testing correct? >> It has a single escaped space. > > And that's correct (I was wrong before).  A directory string of > N spaces normalizes to a single space, which must be escaped in > the DN. > > So it does seem like you and Brian are simply not running the > same code. The only difference between my current RE23 tree and 2.3.30 is in syncprov.c which is obviously not involved here. I would guess Brian's issue may be libsasl2 related, and no longer something resident in the OpenLDAP code. (E.g., conflicting libdb versions.) --    -- Howard Chu    Chief Architect, Symas Corp.  <a href="http://www.symas.com"> http://www.symas.com</a>    Director, Highland Sun        <a href="http://highlandsun.com/hyc">http://highlandsun.com/hyc</a>    OpenLDAP Core Team            <a href="http://www.openldap.org/project/">http://www.openldap.org/project/ </a> </blockquote></div> ------=_Part_2868_7949219.1164737844232--

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 28 Nov '06

28 Nov '06

Kurt D. Zeilenga wrote: > At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: >> Kurt(a)OpenLDAP.org wrote: >>> 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? >> It has a single escaped space. > > And that's correct (I was wrong before). A directory string of > N spaces normalizes to a single space, which must be escaped in > the DN. > > So it does seem like you and Brian are simply not running the > same code. The only difference between my current RE23 tree and 2.3.30 is in syncprov.c which is obviously not involved here. I would guess Brian's issue may be libsasl2 related, and no longer something resident in the OpenLDAP code. (E.g., conflicting libdb versions.) -- -- 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/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 28 Nov '06

28 Nov '06

At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: >Kurt(a)OpenLDAP.org wrote: >> 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? > >It has a single escaped space. And that's correct (I was wrong before). A directory string of N spaces normalizes to a single space, which must be escaped in the DN. So it does seem like you and Brian are simply not running the same code. -- Kurt >Here's the log with 256 characters >instead of 1024: > > >>> slap_listener(ldap://:9011)connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=8 > 0000: 30 17 02 02 04 e7 60 11 0.....`. >ldap_read: want=17, got=17 > 0000: 02 01 03 04 00 a3 0a 04 08 43 52 41 4d 2d 4d 44 >.........CRAM-MD > 0010: 35 5 >ber_get_next: tag 0x30 len 23 contents: >ber_get_next >ldap_read: want=8 error=Resource temporarily unavailable >ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) >do_bind >ber_scanf fmt ({imt) ber: >ber_scanf fmt ({m) ber: >ber_scanf fmt (}}) ber: > >>> dnPrettyNormal: <> ><<< dnPrettyNormal: <>, <> >do_sasl_bind: dn () mech CRAM-MD5 >==> sasl_bind: dn="" mech=CRAM-MD5 datalen=0 >send_ldap_sasl: err=14 len=38 >send_ldap_response: msgid=1255 tag=97 err=14 >ber_flush: 55 bytes to sd 12 > 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 >05....a/........ > 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 >&<942849719.7058 > 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d >659(a)mandolin.sym > 0030: 61 73 2e 63 6f 6d 3e as.com> >ldap_write: want=55, written=55 > 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 >05....a/........ > 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 >&<942849719.7058 > 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d >659(a)mandolin.sym > 0030: 61 73 2e 63 6f 6d 3e as.com> ><== slap_sasl_bind: rc=14 >connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=8 > 0000: 30 82 01 1f 02 02 04 e6 0....... >ldap_read: want=283, got=283 > 0000: 60 82 01 17 02 01 03 04 00 a3 82 01 0e 04 08 43 >`..............C > 0010: 52 41 4d 2d 4d 44 35 04 82 01 00 20 20 20 20 20 RAM-MD5.... > 0020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0030: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0040: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0050: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0060: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0080: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0090: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00a0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00b0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00c0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00d0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00e0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00f0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0100: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0110: 20 20 20 20 20 20 20 20 20 20 20 >ber_get_next: tag 0x30 len 287 contents: >ber_get_next >ldap_read: want=8 error=Resource temporarily unavailable >ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) >connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=0 > >ber_get_next on fd 12 failed errno=0 (Success) >connection_closing: readying conn=2 sd=12 for close >connection_close: deferring conn=2 sd=12 >do_bind >ber_scanf fmt ({imt) ber: >ber_scanf fmt ({m) ber: >ber_scanf fmt (m) ber: >ber_scanf fmt (}}) ber: > >>> dnPrettyNormal: <> ><<< dnPrettyNormal: <>, <> >do_sasl_bind: dn () mech CRAM-MD5 >==> sasl_bind: dn="" mech=<continuing> datalen=256 >SASL Canonicalize [conn=2]: authcid=" > > > > " >slap_sasl_getdn: conn 2 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=2]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" >SASL [conn=2] Failure: no secret in database >send_ldap_result: conn=2 op=1 p=3 >send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no >secret in database" >send_ldap_response: msgid=1254 tag=97 err=49 ><== slap_sasl_bind: rc=49 >connection_resched: attempting closing conn=2 sd=12 >connection_close: conn=2 sd=12 > > > >-- > -- 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/

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 28 Nov '06

28 Nov '06

Kurt(a)OpenLDAP.org wrote: > 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? It has a single escaped space. Here's the log with 256 characters instead of 1024: >>> slap_listener(ldap://:9011)connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=8 0000: 30 17 02 02 04 e7 60 11 0.....`. ldap_read: want=17, got=17 0000: 02 01 03 04 00 a3 0a 04 08 43 52 41 4d 2d 4d 44 .........CRAM-MD 0010: 35 5 ber_get_next: tag 0x30 len 23 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=CRAM-MD5 datalen=0 send_ldap_sasl: err=14 len=38 send_ldap_response: msgid=1255 tag=97 err=14 ber_flush: 55 bytes to sd 12 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 05....a/........ 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 &<942849719.7058 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d 659(a)mandolin.sym 0030: 61 73 2e 63 6f 6d 3e as.com> ldap_write: want=55, written=55 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 05....a/........ 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 &<942849719.7058 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d 659(a)mandolin.sym 0030: 61 73 2e 63 6f 6d 3e as.com> <== slap_sasl_bind: rc=14 connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 1f 02 02 04 e6 0....... ldap_read: want=283, got=283 0000: 60 82 01 17 02 01 03 04 00 a3 82 01 0e 04 08 43 `..............C 0010: 52 41 4d 2d 4d 44 35 04 82 01 00 20 20 20 20 20 RAM-MD5.... 0020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0030: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0040: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0050: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0060: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0080: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0090: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00a0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00b0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00c0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00d0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00e0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00f0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0100: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0110: 20 20 20 20 20 20 20 20 20 20 20 ber_get_next: tag 0x30 len 287 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 12 failed errno=0 (Success) connection_closing: readying conn=2 sd=12 for close connection_close: deferring conn=2 sd=12 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=256 SASL Canonicalize [conn=2]: authcid=" " slap_sasl_getdn: conn 2 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=2]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" SASL [conn=2] Failure: no secret in database send_ldap_result: conn=2 op=1 p=3 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" send_ldap_response: msgid=1254 tag=97 err=49 <== slap_sasl_bind: rc=49 connection_resched: attempting closing conn=2 sd=12 connection_close: conn=2 sd=12 -- -- 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/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 28 Nov '06

28 Nov '06

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/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 28 Nov '06

28 Nov '06

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/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 28 Nov '06

28 Nov '06

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/

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 28 Nov '06

28 Nov '06

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/

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_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, 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). 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. Brian ber_scanf fmt (}}) ber: ber_dump: buf=3D0x09efba28 = ptr=3D0x09efbe47 end=3D0x09efbe47 len=3D0 >>> dnPrettyNorma= l: <> <<< dnPrettyNormal: <>, <> do_sasl_b= ind: dn () mech CRAM-MD5 =3D=3D> sasl_bind: dn=3D"" mech=3D<continuing> datal= en=3D1024 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;            =         " slap_sasl_getdn: conn 21 id=3D      &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;    [len=3D255] =3D> ldap_dn2bv(16) <=3D ldap_dn2bv(uid=3D\20  &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;            \20,= cn=3DCRAM-MD5,cn=3Dauth)=3D0 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 >>> dnNormalize: <uid=3D\20     &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;          \20,cn=3DCRAM-MD5,c= n=3Dauth> =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) <=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 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3D\20,cn=3Dcram-md5,c= n=3Dauth)=3D0 <<< dnNormalize: <uid=3D\20,cn=3Dcram-md5,cn= =3Dauth> =3D=3D>slap_sasl2dn: converting SASL name uid=3D\20,cn=3D= cram-md5,cn=3Dauth to a DN slap_authz_regexp: converting SASL name uid=3D\20,cn=3Dcram-md5,cn=3Dau= th <=3D=3Dslap_sasl2dn: Converted SASL name to <nothing> SAS= L Canonicalize [conn=3D21]: slapAuthcDN=3D"uid=3D\20,cn=3Dcram-md5,cn= =3Dauth" ------=_Part_8120_20176863.1164676496288--

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by hyc＠symas.com 27 Nov '06

27 Nov '06

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/

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 27 Nov '06

27 Nov '06

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

1 0

(ITS#4763) slapd crashed with ldapsearch command without arguments
by saint.cn＠gmail.com 27 Nov '06

27 Nov '06

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.

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 25 Nov '06

25 Nov '06

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/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it 25 Nov '06

25 Nov '06

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 ------------------------------------------

1 0

Re: (ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 25 Nov '06

25 Nov '06

michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > To be honest, I don't quite see the point in keeping sorted a set of values that by definition is dynamically built. There seems to be contradiction between the two overlays that prevents them from being used together anyway. If your intention is to partition a tree so that the intersection of data subjected to valsort and data subjected to dynlist is empty, then I guess the solution is to use the <attri> and <baseDN> parameters of valsort to exclude those entries that are subjected to dynlist. If this is not enough, you could ask for an enhancement that turns the <attr> <baseDN> into a more general specification that allows increased granularity; for example, an attr and a filter, which incidentally could be specified by means of an URL so that base, attribute list, scope and filter can be present. 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 ------------------------------------------

1 0

Re: (ITS#4762) Bugs in meta backend
by Kurt＠OpenLDAP.org 24 Nov '06

24 Nov '06

As there is no major security issue here, this report is now public. At 03:01 AM 11/24/2006, jerome.thevenet(a)aviation-civile.gouv.fr wrote: >Full_Name: >Version: 2.3.27 >OS: ubuntu >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (213.41.243.192) > > >In Database meta: >When we define several servers (uri: ldap//....), >onerr CONTINUE > >If all servers are ok, the research is ok. >But if one of them is off, the result of a research is error 52 even if the >others send good result. > >Thanks

1 0

RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 24 Nov '06

24 Nov '06

> > Fixed (differently) in HEAD/re23; please test. Thanks for > reporting. p. > Just looked at your changes, of course it makes sense to put this in a common function. I will test over the weekend Gerald > > > 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 > ------------------------------------------ > > > > ** Virus checked by BB-5000 Mailfilter ** > !DSPAM:4566ce0e132554386119908! > ** Virus checked by BB-5000 Mailfilter **

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

richter(a)ecos.de wrote: Fixed (differently) in HEAD/re23; please test. Thanks for reporting. 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 ------------------------------------------

1 0

(ITS#4761) error in "group" authorization parsing
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando When an authorization rule using groups, like "group:<dn>" is used, the default member attribute "member" is erroneously set to an empy berval, resulting in an invalid filter being used for the internal lookup to check for membership. A workaround consists in avoiding defaults: "group/<oc>/<at>:<dn>". "group/<oc>:<dn>" appears to work as intended, i.e. in this case the default attribute is correctly used. A fix is coming. p.

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Gerald Richter wrote: >> I'm not sure I understand the issue you describe. In fact, >> groups appear to be cached on a per-operation basis, and user >> membership is evaluated using the authorized identity (B in >> your case), so the behavior should be correct. I've made a >> simple check using re23 and things appear to work as >> expected: I log in as a user (A) that is not in a group and >> authorize as a user (B) that is in that group. I previously >> configured slapd so that only members of that group are >> allowed to read an attribute in the whole db (say "cn"). >> Things work as expected: if I login as user A I can't see >> "cn", but if I either log in as user B, or login as user A >> and proxyAuthz as B I can read the "cn". Can you provide a >> simple example (slapd.conf, db.ldif and sequence of >> operations, e.g. in a shell script) that causes the issue you see? >> >> > > I think the point is that the group must be evaluated already in the search > for the AuthzTo attribute. > > So my User A has the AuthzTo attribute set to User B and I have the > following access control: > > > access to * > by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" > write > by * break > > ... > > > access to * attrs=authzTo > by self read > by * break > > ... > > User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when > I log in as user A and proxyAuth to Openldap will evaluate the group > membership for A and cache it, during the search for the ACL to authzTo. A > is not member. > > Now when the actual search operation takes places, openldap will used the > cached result (which was "is not member"), which is wrong because the user > has changed since the group membership was cached. > > I hope this makes the problem more clear (I have a test environment here, > but it is very complex and easy transferable) > OK, I see. In my test ACLs for authzTo didn't make use of groups. It makes sense to clear out identity related cached stuff when the identity changes. What I'm looking for is a __simple__ test that exploits the feature. This would allow to clearly spot the issue in the first place, and prepare a regression test. I'll do some more testing. 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 ------------------------------------------

1 0

RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 24 Nov '06

24 Nov '06

> I'm not sure I understand the issue you describe. In fact, > groups appear to be cached on a per-operation basis, and user > membership is evaluated using the authorized identity (B in > your case), so the behavior should be correct. I've made a > simple check using re23 and things appear to work as > expected: I log in as a user (A) that is not in a group and > authorize as a user (B) that is in that group. I previously > configured slapd so that only members of that group are > allowed to read an attribute in the whole db (say "cn"). > Things work as expected: if I login as user A I can't see > "cn", but if I either log in as user B, or login as user A > and proxyAuthz as B I can read the "cn". Can you provide a > simple example (slapd.conf, db.ldif and sequence of > operations, e.g. in a shell script) that causes the issue you see? > I think the point is that the group must be evaluated already in the search for the AuthzTo attribute. So my User A has the AuthzTo attribute set to User B and I have the following access control: access to * by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" write by * break ... access to * attrs=authzTo by self read by * break ... User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when I log in as user A and proxyAuth to Openldap will evaluate the group membership for A and cache it, during the search for the ACL to authzTo. A is not member. Now when the actual search operation takes places, openldap will used the cached result (which was "is not member"), which is wrong because the user has changed since the group membership was cached. I hope this makes the problem more clear (I have a test environment here, but it is very complex and easy transferable) Gerald ** Virus checked by BB-5000 Mailfilter **

1 0

RE: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de 24 Nov '06

24 Nov '06

> > I have no objection at accepting this code, since it seems to > create no backwards compatibility issues but rather solves a > (irrelevant?) compatibility issue with an ancient version of > the code in an area that I believe to be of questionable > usefulness. At least it had help me by upgrading a bunch of servers from 2.1 which used this feature. > In fact, ACIs have been deprecated ever since, > so I wouldn't spend too much time with them. If there's no > IPR issues (as, for what I can tell, there appear to be > none), I'd try to apply the patch to HEAD code. > Thanks. We use ACI, because we have a setup where we replicate different parts of the tree to different slave ldap servers. By using ACI's the access information get's replicated too. To get the same behaviour with ACL's it would be much more compilcated, because we would need to sort out which ACL's to replicate and which not, because not simply subtrees are replicated (we cannot simply replicate all ACL's because this would leak too much informations). >From this point of view ACI are quite usefull, at least for us. Gerald ** Virus checked by BB-5000 Mailfilter **

1 0

Re: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by ando＠sys-net.it 23 Nov '06

23 Nov '06

richter(a)ecos.de wrote: I have no objection at accepting this code, since it seems to create no backwards compatibility issues but rather solves a (irrelevant?) compatibility issue with an ancient version of the code in an area that I believe to be of questionable usefulness. In fact, ACIs have been deprecated ever since, so I wouldn't spend too much time with them. If there's no IPR issues (as, for what I can tell, there appear to be none), I'd try to apply the patch to HEAD code. 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 ------------------------------------------

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 23 Nov '06

23 Nov '06

richter(a)ecos.de wrote: > I noticed that when I use the proxyAuth control group members are not correctly > resolved. > > What I do is to login as user A and do a search with proxyAuth control with an > authzid of user B. > > User B is member of a group, which grants him access to the some items. User A > is not. > > When directly logging in as user B, everything is ok. Using proxyAuth user B > doesn't have access to the items that are granted to the group. > > The reason is that the group membership is cached, and therefore users A > membership is used for ACL evaluation, instead of users B membership. > > The attached patch, simply deletes all cached groups, when inside the proxyAuth > control setup, which resolvs this issue. > I'm not sure I understand the issue you describe. In fact, groups appear to be cached on a per-operation basis, and user membership is evaluated using the authorized identity (B in your case), so the behavior should be correct. I've made a simple check using re23 and things appear to work as expected: I log in as a user (A) that is not in a group and authorize as a user (B) that is in that group. I previously configured slapd so that only members of that group are allowed to read an attribute in the whole db (say "cn"). Things work as expected: if I login as user A I can't see "cn", but if I either log in as user B, or login as user A and proxyAuthz as B I can read the "cn". Can you provide a simple example (slapd.conf, db.ldif and sequence of operations, e.g. in a shell script) that causes the issue you see? 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 ------------------------------------------

1 0

(ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 23 Nov '06

23 Nov '06

Full_Name: Gerald Richter Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.2.patch Submission from: (NULL) (194.95.226.11) Hi, I noticed that when I use the proxyAuth control group members are not correctly resolved. What I do is to login as user A and do a search with proxyAuth control with an authzid of user B. User B is member of a group, which grants him access to the some items. User A is not. When directly logging in as user B, everything is ok. Using proxyAuth user B doesn't have access to the items that are granted to the group. The reason is that the group membership is cached, and therefore users A membership is used for ACL evaluation, instead of users B membership. The attached patch, simply deletes all cached groups, when inside the proxyAuth control setup, which resolvs this issue. Gerald This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any license of ecos GmbH. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de 23 Nov '06

23 Nov '06

Full_Name: Gerald Richter Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.patch Submission from: (NULL) (194.95.226.11) Hi, I found that due to the rewrite of ACI code, the possiblity to specify more than one attribute in one ACI entry has gone lost. We discussed this already at the beginning of the year on the mailing list. I have made a patch, that is in heavy production use on several systems for some time now, that again (as in OpenLDAP 2.1) allows to have multiple attributes in one ACI. This is not only a compatibility issue, but also improves the performance of ACI handling, if you need to specifiy a lot of attributes. The patch also adds some more debugging output, that allows to easyer understand what's going on, when you have set some ACI and it does not have the desired result. Gerald This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any license of ecos GmbH. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by michael.heep＠o2.com 23 Nov '06

23 Nov '06

Full_Name: Michael Heep Version: 2.3.30 OS: Linux (RHES30) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Hi, the following valsort + dynlist combination causes slapd to utilize 100% cpu time when issueing searches against parts of the DIT containing attribute-value pairs "created" by dynlist: overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend When run independent both overlays work flawlessly.

1 0

ITS#4600 slap_mods_check duplicate check
by hyc＠symas.com 23 Nov '06

23 Nov '06

There *is* a bug here, as Nick pointed out in the first followup - slap_mods2entry does a redundant check for duplicates. All of the mods that get fed into this function have already been checked by slap_mods_check. So we're doing an n^2 check twice on every add, no wonder LDAPAdds are so slow... -- -- 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/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 21 Nov '06

21 Nov '06

Since test033 didn't replicate, I ran librtc against a full production config. The SEGV occurred here (note we're not inside malloc due to librtc redzone features): <rtc> Write to unallocated (wua) on thread 11: Attempting to write 1 byte at address 0xc886b0 which is just past heap block of size 128 bytes at 0xc88630 This block was allocated from: [1] default_malloc_ex() at line 79 in "mem.c" [2] CRYPTO_malloc() at line 304 in "mem.c" [3] RSA_eay_private_decrypt() at line 488 in "rsa_eay.c" [4] RSA_private_decrypt() at line 292 in "rsa_lib.c" [5] ssl3_get_client_key_exchange() at line 1454 in "s3_srvr.c" [6] ssl3_accept() at line 448 in "s3_srvr.c" [7] SSL_accept() at line 816 in "ssl_lib.c" [8] ldap_pvt_tls_accept() at line 863 in "tls.c" Location of error: current thread: t@11 =>[1] BN_bn2bin(a = 0xd93ff3d4, to = 0xc886b0 ""), line 649 in "bn_lib.c" [2] RSA_eay_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 576 in "rsa_eay.c" [3] RSA_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 292 in "rsa_lib.c" [4] ssl3_get_client_key_exchange(s = 0xc74500), line 1454 in "s3_srvr.c" [5] ssl3_accept(s = 0xc74500), line 448 in "s3_srvr.c" [6] SSL_accept(s = 0xc74500), line 816 in "ssl_lib.c" [7] ldap_pvt_tls_accept(sb = 0xc74068, ctx_arg = 0xb53bd8), line 863 in "tls.c" [8] connection_read(s = 46), line 1337 in "connection.c" [9] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c" This system is running OpenSSL 0.9.7l, although I've seen the #4723 segfault (not under debugger, alas) on 0.9.7d systems as well. Is there any easy way to turn on traffic encryption in 'make test', possibly with some on-the-fly self-gen certs?

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by Frank.Swasey＠uvm.edu 20 Nov '06

20 Nov '06

This is a cryptographically signed message in MIME format. --------------ms020103070007040700000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm slow reading my email (well 18 days isn't so bad really... ahem...) On 11/2/06 2:42 PM, quanah(a)stanford.edu wrote: > As for #2, I grant such a release for the work I've done on the script. > > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Yes, I do grant this release. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------ms020103070007040700000908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0 /joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN 0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy +z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7 ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTEyMDE5NTUxN1owIwYJKoZIhvcNAQkEMRYEFEe5 R0tOqDV5mZSEX9tMzc1x2JoeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQB5jfu/W/bTIPufVHhrEsZS19DtAZXNQisiNsDTRGtdQGyyS9w2 NE0w5B0Lhbhg+dgwBGvd03/OqxwguatStF0fpgW2sFK3pbvClmRA7mXte5d51GNP49COPd4C R1dLsOtzmhHb2YJ8Cg46vZWE/UdgGYYoV4zStPNJHs3Z07pQ5pCBMhd4l/BZht+BPgNiirLv UskWVwSwUfGxfgEka9yG4KLCQdhL44oUXRcawWfrOPcmN80jrXHp6FnsNSJ43ifztqK4QKyY idUeA+NEmv3Ss5AO6PkvC51rsr2qmLkMeczl/ZuvcxGaDDloBibCdWJu5R81pRoTO0UdPfiw uwbIAAAAAAAA --------------ms020103070007040700000908--

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 20 Nov '06

20 Nov '06

At 12:36 AM 11/20/2006, michael(a)stroeder.com wrote: >Kurt D. Zeilenga wrote: >> At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >>> >>>I'd like to see support for RFC 3045 in slapd. >> >> The only reasonably decent use of such attributes is for >> administrators to determine whether they need to upgrade >> some software or not > >Yes, that's what I'm after. This purpose is, I think, somewhat beyond the intended purpose of the vendorName/Version attributes. These attributes appear to be intended to be used by general LDAP clients, not just administrative clients, for "limited feature discovery". The vendorName/Version you might want reported for "limited feature discovery" might be quite different than what you want reported for "need to upgrade" purposes. And for "need to upgrade" purposes, one needs to know not only the version of the protocol engine (slapd(8)), but version of backend codes, overlay codes, underlying libraries, etc.. >> We provide cn=monitor for this purpose. > >This is proprietary. Think of vendor-independent management/monitoring >software which just gives an terse overview. Generally speaking, DSA administrative interfaces are not standardized. (Which is, to some degree, why I think use of vendorName/Version for administrative purposes is beyond the intentions of these attributes.) >> While it certainly is possible for a client to abuse >> cn=monitor version information, the very fact that the >> version information is in cn=monitor, which generally >> requires special authorization to read, instead of >> the root dse, which generally is readable by most >> every client, is effective in discouraging this abuse. > >The server admin can easily define access control for vendor information >in root DSE. The sample slapd.conf could endorse this. Or another value >for configuration directive 'allow'. Yes, but... Kurt

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 20 Nov '06

20 Nov '06

Kurt D. Zeilenga wrote: > At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >> >>I'd like to see support for RFC 3045 in slapd. > > The only reasonably decent use of such attributes is for > administrators to determine whether they need to upgrade > some software or not Yes, that's what I'm after. > We provide cn=monitor for this purpose. This is proprietary. Think of vendor-independent management/monitoring software which just gives an terse overview. > While it certainly is possible for a client to abuse > cn=monitor version information, the very fact that the > version information is in cn=monitor, which generally > requires special authorization to read, instead of > the root dse, which generally is readable by most > every client, is effective in discouraging this abuse. The server admin can easily define access control for vendor information in root DSE. The sample slapd.conf could endorse this. Or another value for configuration directive 'allow'. Ciao, Michael.

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 20 Nov '06

20 Nov '06

At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >Full_Name: Michael Ströder >Version: not relevant >OS: not relevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (83.124.27.203) > > >HI! > >I'd like to see support for RFC 3045 in slapd. The only reasonably decent use of such attributes is for administrators to determine whether they need to upgrade some software or not (though use of a protocol attribute for this purpose is somewhat problematic). We provide cn=monitor for this purpose. The primary use (or I should say misuse) of such strings is for server behavior discovery (whether the behavior is due to a feature or a bug). As this use leads to interoperability problems (as illustrated by the HTTP "mozilla" compatibility problems), we must allow spoofing and should discourage this use. We support the former via the rootdse configuration option. We support the latter by not providing any values by default. While it certainly is possible for a client to abuse cn=monitor version information, the very fact that the version information is in cn=monitor, which generally requires special authorization to read, instead of the root dse, which generally is readable by most every client, is effective in discouraging this abuse. I think it reasonable to assume any administrative tool for determining whether an OpenLDAP server is up to date would have appropriate authorization to read the cn=monitor values. I note that such tools should not assume a server needs not be upgraded simply because the version is high enough. There easily could be dependent software whose version is not high enough. It would be good for cn=monitor to not only expose the OpenLDAP version information, but to expose version information for dependent software. Of course, as there is an endless number of dependent software, this upgrade detection approach problematic. Seems it would be better to use tools that ran directly on the box to determine whether a server's software needed to be upgraded. But I digresss. In the past we have rejected submissions to extend slapd(8) to generate these values, hence I think this feature request should be closed. However, such closure certainly doesn't preclude someone from implementing **additional** vendorName/Version functionality and submitting it for consideration. There is one aspect of our current vendorName/Version support that is lacking is in dealing with multiple broken clients requiring different vendorName/Version strings. An overlay which spoofed these strings on a configurable basis, whether by authorization identity and/or IP address and/or other authorization factor, would be an interesting functionality addition. Kurt

1 0

(ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 19 Nov '06

19 Nov '06

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.27.203) HI! I'd like to see support for RFC 3045 in slapd. Yes, I know I can set this using configuration directive rootDSE in slapd.conf. But that doesn't really help, especially regarding 'vendorVersion'. Ciao, Michael.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 17 Nov '06

17 Nov '06

Still no good with 2.3.30. I ran 2.3.30 test033 under librtc (valgrind-esque) and it came up clean, so this has to be intermittent or more than a simple config can instigate. [1] t_delete(0xc2c398, 0x50, 0x992e508, 0xfec3c000, 0x0, 0x0), at 0xfebc783c [2] _malloc_unlocked(0x25, 0x0, 0xcb4b0, 0xfec3c000, 0x0, 0x99d3829), at 0xfebc6ecc [3] malloc(0x25, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xd573ef7d), at 0xfebc6d00 =>[4] ber_memalloc_x(s = 37U, ctx = (nil)), line 226 in "memory.c" [5] ch_malloc(size = 37U), line 54 in "ch_malloc.c" [6] hdb_fix_dn(e = 0x99d3630, checkit = 0), line 445 in "dn2id.c" [7] hdb_cache_find_id(op = 0xd57ff4f4, tid = (nil), id = 7586U, eip = 0xd573f2e8, islocked = 0, locker = 150U, lock = 0xd573f26c), line 765 in "cache.c" [8] hdb_search(op = 0xd57ff4f4, rs = 0xd57ff4b8), line 696 in "search.c" [9] syncprov_findcsn(op = 0x3edff0, mode = FIND_PRESENT), line 685 in "syncprov.c" [10] syncprov_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 2056 in "syncprov.c" [11] overlay_op_walk(op = 0x3edff0, rs = 0xd57ffd50, which = op_search, oi = 0x31bfb8, on = 0x31c0b0), line 491 in "backover.c" [12] over_op_func(op = 0x3edff0, rs = 0xd57ffd50, which = op_search), line 551 in "backover.c" [13] over_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 573 in "backover.c" [14] fe_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 355 in "search.c" [15] do_search(op = 0x3edff0, rs = 0xd57ffd50), line 217 in "search.c" [16] connection_operation(ctx = 0xd57ffe14, arg_v = 0x3edff0), line 1122 in "connection.c" [17] ldap_int_thread_pool_wrapper(xpool = 0x2c5df0), line 478 in "tpool.c"

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by quanah＠stanford.edu 17 Nov '06

17 Nov '06

--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? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

RE: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by Damon.Groenveld＠ca.com 17 Nov '06

17 Nov '06

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. 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, so I was hoping that some advice might come while someone looked at the problem (if or when it was deemed important enough). Damon Groenveld CA Architect, Development tel: +61 3 9727 8920 fax: +61 3 9727 3491 mobile: +61 419 922 326 damon.groenveld(a)ca.com -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Friday, 17 November 2006 4:59 PM To: Groenveld, Damon Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- 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/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 17 Nov '06

17 Nov '06

damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- 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/

1 0

(ITS#4756) IPv6 Addresses are not supported in ACL peername
by damon.groenveld＠ca.com 17 Nov '06

17 Nov '06

Full_Name: Damon Groenveld Version: LATEST OS: Solaris, WinXP, Linux, AIX, HP-UX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.224.6.218) There does not seem to be the ability to specify an IPv6 address in the peername part of the ACL. Is there any other way to restrict access to a host IP address when using only IPv6 addresses?

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 17 Nov '06

17 Nov '06

On Thu, 16 Nov 2006, Howard Chu wrote: > Since the rid is supposed to be unique, would you settle for that? > Particularly since there may be multiple sessions to the same host... Yes, that will do nicely. In the meantime I was getting it to print si->si_bindconf.sb_uri.bv_val, as I sort of need it right now... -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 17 Nov '06

17 Nov '06

daveh(a)ci.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.3.27 > OS: FreeBSD 4.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.65.182.30) > > > We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). > Should a syncrepl fail, it would be good to know just which peer was causing the > trouble. Could this name (or IP address, or syncrepl host etc) be passed to the > Debug() call? Since the rid is supposed to be unique, would you settle for that? Particularly since there may be multiple sessions to the same host... -- -- 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/

1 0

(ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 17 Nov '06

17 Nov '06

Full_Name: Dave Horsfall Version: 2.3.27 OS: FreeBSD 4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). Should a syncrepl fail, it would be good to know just which peer was causing the trouble. Could this name (or IP address, or syncrepl host etc) be passed to the Debug() call?

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by hyc＠symas.com 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.4 > OS: FC6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? No, that is impossible. A syncrepl consumer is a client. A client must have the plaintext in order to authenticate. -- -- 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/

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ando＠sys-net.it 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? > Please don't use the ITS to ask software usage (or development trends) questions. The syncrepl consumer acts as a client with respect to the producer DSA; as a consequence, to be able to perform simple bind, it needs to provide the credentials in cleartext. Either you use a bindmethod different from simple (e.g. SASL) which does not require cleartext credentials (e.g. GSSAPI) or you'll ever need to provide cleartext credentials. This ITS will be closed. 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 ------------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs