openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5540) Normalization assertion in attr.c
by hyc＠symas.com 29 Jun '08

29 Jun '08

unix.gurus(a)gmail.com wrote: > I've uploaded a patch that adds an equality matching rule to the > schema for olcRootDN and olcSchemaDN so that the normalization matches > the schema. These attributes are already normalized wherever they are > generated, and their normalized values are used in bvmatches, so > removing the nvals instead of modifying the schema would result extra > normalization calls later. > ftp://ftp.openldap.org/incoming/sean-burford-rootdn-080628.patch Committed, thanks. > If someone wants to accept or comment on what needs fixing in the > patch below, that would help me to generate the rest of the patches: > ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… If it makes life easier, we can add the DN eq rule to monitorContext and configContext. Since they're OpenLDAP-specific attributes we can make this change without any repercussions. IMO, it really needs to be added to namingContexts since that's multivalued. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 29 Jun '08

29 Jun '08

I've uploaded a patch that adds an equality matching rule to the schema for olcRootDN and olcSchemaDN so that the normalization matches the schema. These attributes are already normalized wherever they are generated, and their normalized values are used in bvmatches, so removing the nvals instead of modifying the schema would result extra normalization calls later. ftp://ftp.openldap.org/incoming/sean-burford-rootdn-080628.patch If someone wants to accept or comment on what needs fixing in the patch below, that would help me to generate the rest of the patches: ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 29 Jun '08

29 Jun '08

I've uploaded a tiny patch that checks the return code from structural_class() in config_build_entry() and outputs an error message if it fails. This makes it easier to debug structural_class() failures before too much other code is run: ftp://ftp.openldap.org/incoming/sean-burford-structural-error-080628.patch -- Thanks, Sean Burford

1 0

Re: (ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by h.b.furuseth＠usit.uio.no 27 Jun '08

27 Jun '08

Howard Chu writes: > Sounds like this works as designed. The docs tell you that > either CACERT or CACERTDIR must be explicitly configured. Maybe, but in that case the bug is that configuring them to an irrelevant certificate works as a "use the OpenSSL defaults" flag. Which is weird at best. And broke our testing: We thought we checked that certain of our users and clients had updated to use our new cert, but actually we just checked that the OpenSSL installations on the test hosts had the CyberTrust root cert. Which got really confusing when we later tried to get some test clients without the new cert to fail. However if we turn this off (remove SSL_CTX_set_default_verify_paths()), we'll likely break existing installations that (intentionally or not) make use of this feature. (Like some of the clients we supposedly tested:-) Thus it seemed best to always load them. Though OTOH I suppose it's not such a good idea to trust a bunch of certs without being asked to do so. Yet if you can't trust your OpenSSL maintainer... Could add a keyword to turn on (or off) loading of defaults, but I do think it should be independent of whether TLS_CACERT(DIR) have been set. -- Hallvard

1 0

Re: (ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by hyc＠symas.com 27 Jun '08

27 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, 2.3, 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > OpenLDAP only uses the default certificates installed with OpenSSL if > TLS_CACERT or TLS_CACERTDIR is set. Or presumably > TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for > servers seem to require a certificate chain from that directory anyway. > Sounds like this works as designed. The docs tell you that either CACERT or CACERTDIR must be explicitly configured. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5582) Default OpenSSL certs are only used when TLS_CACERT(DIR)
by h.b.furuseth＠usit.uio.no 27 Jun '08

27 Jun '08

Full_Name: Hallvard B Furuseth Version: HEAD, 2.3, 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-080627.diff Submission from: (NULL) (129.240.6.233) Submitted by: hallvard OpenLDAP only uses the default certificates installed with OpenSSL if TLS_CACERT or TLS_CACERTDIR is set. Or presumably TLSCACertificate<File/Dir> in servers, but the libldap/tls.c code for servers seem to require a certificate chain from that directory anyway. To reproduce: $ export LDAPCONF=/dev/null $ ldapwhoami -xZZh ldap.uio.no certificate verify failed $ export LDAPTLS_CACERT="*any* certificate.pem file" $ ldapwhoami -xZZh ldap.uio.no anonymous Or if it still fails, find where OpenSSL wants its default certs: strace ldapwhoami -xZZh ldap.uio.no 2>&1 | grep ssl and temporarily append the root cert which signed our server cert from https://secure.globalsign.net/cacert/CT_Root_CA.pem Then try again. Something like /usr/local/ssl/cert.pem. $ ldapwhoami -xZZh ldap.uio.no anonymous $ unset LDAPTLS_CACERT; ldapwhoami -xZZh ldap.uio.no certificate verify failed The relevant code is in libldap/tls.c:ldap_int_tls_init_ctx(). I enclose a tentative patch which fixes the above problem, but I'm not sure it's the right one for servers and GnuTLS. The GnuTLS branch does not require a server TLSCACertificateFile, but the OpenSSL code does. I don't know if GnuTLS has a default which is used instead, nor if OpenSSL can have that.

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 27 Jun '08

27 Jun '08

On Fri, Jun 27, 2008 at 03:17:10PM +0000, Andrew Findlay wrote: > Hmm: I now have a crasher in attr_valadd when adding a member to a > group that already contains two members. Not sure yet whether I caused it > with the minus-one-line fix above, or whether I have uncovered a new > problem. > for ( j = a->a_numvals; j >= slot; j-- ) { > a->a_vals[j+1] = a->a_vals[j]; <==================== Crash here > if ( nvals ) > a->a_nvals[j+1] = a->a_nvals[j]; > } ... so I stepped through that in GDB. j did indeed start at 2 and decrement to 0, but then it kept going! 407 for ( j = a->a_numvals; j >= slot; j-- ) { (gdb) 408 a->a_vals[j+1] = a->a_vals[j]; (gdb) print j $17 = 1 (gdb) print a->a_vals[j] $18 = {bv_len = 97, bv_val = 0x847b680 "uniqueIdentifier=a3,ou=accounts,uniqueIdentifier=to-a,dc=orgs,...."} (gdb) n 409 if ( nvals ) (gdb) 410 a->a_nvals[j+1] = a->a_nvals[j]; (gdb) 407 for ( j = a->a_numvals; j >= slot; j-- ) { (gdb) 408 a->a_vals[j+1] = a->a_vals[j]; (gdb) print print a->a_vals[j] A syntax error in expression, near `a->a_vals[j]'. (gdb) print a->a_vals[j] $19 = {bv_len = 96, bv_val = 0x847b618 "uniqueIdentifier=ag1,ou=groups,uniqueIdentifier=to-a,dc=orgs,..."} (gdb) n slap_client_connect: URI=ldap://localhost:2389/ DN="cn=replicator,dc=accounts,...." ldap_sasl_bind_s failed (-1) do_syncrepl: rid=002 retrying (5 retries left) 409 if ( nvals ) (gdb) 410 a->a_nvals[j+1] = a->a_nvals[j]; (gdb) 407 for ( j = a->a_numvals; j >= slot; j-- ) { (gdb) 408 a->a_vals[j+1] = a->a_vals[j]; (gdb) print j $20 = -1 (gdb) n 409 if ( nvals ) (gdb) print slot $21 = 0 (gdb) n 410 a->a_nvals[j+1] = a->a_nvals[j]; (gdb) slap_client_connect: URI=ldap://localhost:2389/ DN="cn=replicator,dc=accounts,..." ldap_sasl_bind_s failed (-1) do_syncrepl: rid=002 retrying (4 retries left) 407 for ( j = a->a_numvals; j >= slot; j-- ) { (gdb) 408 a->a_vals[j+1] = a->a_vals[j]; (gdb) print j $22 = -2 (gdb) print j >= slot $23 = 1 (gdb) print slot $24 = 0 Curiouser and curiouser cried Alice... (gdb) whatis j type = int (gdb) whatis slot type = unsigned int Aha! Comparing signed and unsigned integers. Could be risky. I don't do much C these days, and I don't see many explicit type-casts in OpenLDAP code. What would be a good-practice solution here? Casting slot to long int seems to work for me so I have updated the patch: ftp://ftp.openldap.org/incoming/andrew.findlay-sortvals-20080627.patch Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 27 Jun '08

27 Jun '08

On Thu, Jun 26, 2008 at 10:00:00AM +0000, Andrew Findlay wrote: > I have uploaded a proposed fix for this: > > ftp://ftp.openldap.org/incoming/andrew-findlay-sortvals-20080626.patch > > My reasoning is that the break statement terminates the loop before > the last value in the list has been compared with the assertion value. > Thus, even if the last value matches, the loop ends with -1 in 'match'. Hmm: I now have a crasher in attr_valadd when adding a member to a group that already contains two members. Not sure yet whether I caused it with the minus-one-line fix above, or whether I have uncovered a new problem. I would expect the new value to sort at the front of the list. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1518945392 (LWP 1431)] 0x0806e650 in attr_valadd (a=0xa6c71084, vals=0x847a148, nvals=0x847a190, nn=1) at attr.c:410 410 a->a_nvals[j+1] = a->a_nvals[j]; (gdb) where #0 0x0806e650 in attr_valadd (a=0xa6c71084, vals=0x847a148, nvals=0x847a190, nn=1) at attr.c:410 #1 0x080b4db3 in modify_add_values (e=0xa5769cb0, mod=0x8479a98, permissive=0, text=0xa576b17c, textbuf=0xa5769bb0 "", textlen=256) at mods.c:155 #2 0x080d0d4e in bdb_modify_internal (op=0x83964e0, tid=0x847b400, modlist=0x8479a98, e=0xa5769cb0, text=0xa576b17c, textbuf=0xa5769bb0 "", textlen=256) at modify.c:101 #3 0x080d1926 in bdb_modify (op=0x83964e0, rs=0xa576b168) at modify.c:578 #4 0x080c6b21 in overlay_op_walk (op=0x83964e0, rs=0xa576b168, which=op_modify, oi=0x82f9a18, on=0x82fa0c8) at backover.c:646 #5 0x080c709d in over_op_func (op=0x83964e0, rs=0xa576b168, which=op_modify) at backover.c:698 #6 0x0807dd36 in fe_op_modify (op=0x83964e0, rs=0xa576b168) at modify.c:300 #7 0x0807e6a8 in do_modify (op=0x83964e0, rs=0xa576b168) at modify.c:175 #8 0x08065646 in connection_operation (ctx=0xa576b238, arg_v=0x83964e0) at connection.c:1084 #9 0x08065c42 in connection_read_thread (ctx=0xa576b238, argv=0x1f) at connection.c:1211 #10 0x0817e454 in ldap_int_thread_pool_wrapper (xpool=0x82b4310) at tpool.c:663 #11 0xb7c19112 in start_thread () from /lib/libpthread.so.0 #12 0xb7ba52ee in clone () from /lib/libc.so.6 (gdb) print j $1 = -305887 (gdb) print a $2 = (Attribute *) 0xa6c71084 (gdb) print *a $3 = {a_desc = 0x82e12e8, a_vals = 0x847ba28, a_nvals = 0x847b6e8, a_numvals = 2, a_flags = 16, a_next = 0xa6c7bd34} (gdb) print slot $4 = 0 (gdb) print nvals $5 = (BerVarray) 0x847a190 (gdb) The relevant code block is this: /* If sorted and old vals exist, must insert */ if (( a->a_flags & SLAP_ATTR_SORTED_VALS ) && a->a_numvals ) { unsigned slot; int j, rc; v2 = nvals ? nvals : vals; for ( i = 0; i < nn; i++ ) { rc = attr_valfind( a, SLAP_MR_EQUALITY | SLAP_MR_VALUE_OF_ASSERTION_SYNTAX | SLAP_MR_ASSERTED_VALUE_NORMALIZED_MATCH | SLAP_MR_ATTRIBUTE_VALUE_NORMALIZED_MATCH, &v2[i], &slot, NULL ); if ( rc != LDAP_NO_SUCH_ATTRIBUTE ) { /* should never happen */ if ( rc == LDAP_SUCCESS ) rc = LDAP_TYPE_OR_VALUE_EXISTS; return rc; } for ( j = a->a_numvals; j >= slot; j-- ) { a->a_vals[j+1] = a->a_vals[j]; <==================== Crash here if ( nvals ) a->a_nvals[j+1] = a->a_nvals[j]; } ber_dupbv( &a->a_nvals[slot], &v2[i] ); if ( nvals ) ber_dupbv( &a->a_vals[slot], &vals[i] ); a->a_numvals++; } BER_BVZERO( &a->a_vals[a->a_numvals] ); if ( a->a_vals != a->a_nvals ) BER_BVZERO( &a->a_nvals[a->a_numvals] ); } else { I cannot see how j got that large negative value. It should have started the loop at 2 (a->a_numvals) and decremented until it reached zero. Must have been overwritten somewhere. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5580) BER Decoding Remote DoS Vulnerability
by hyc＠symas.com 27 Jun '08

27 Jun '08

Howard Chu wrote: > zdi-disclosures(a)tippingpoint.com wrote: >> Full_Name: Cameron Hotchkies >> Version: 2.3.41 >> OS: Gentoo Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.179.208.36) >> >> >> This vulnerability allows remote attackers to deny services on vulnerable >> installations of OpenLDAP. Authentication is not required to exploit this >> vulnerability. > > Thanks for the report, a fix is now in HEAD. Please test. For future reference, it looks like this may have crept in in 2001, rev 1.88/ITS#2465... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5580) BER Decoding Remote DoS Vulnerability
by hyc＠symas.com 27 Jun '08

27 Jun '08

zdi-disclosures(a)tippingpoint.com wrote: > Full_Name: Cameron Hotchkies > Version: 2.3.41 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.179.208.36) > > > This vulnerability allows remote attackers to deny services on vulnerable > installations of OpenLDAP. Authentication is not required to exploit this > vulnerability. Thanks for the report, a fix is now in HEAD. Please test. > The specific flaw exists in the decoding of ASN.1 BER network datagrams. When > the size of a BerElement is specified incorrectly, the application will trigger > an assert(), leading to abnormal program termination. > Tech Details: > > The code exhibiting the problem is located in the function ber_get_next() > function in "libraries/liblber/io.c" . > > The function fails to handle properly BER encoding of an element (tag + length + > content) that contains: > > * exactly 4 bytes long "multi-byte tag" > * exactly 4 bytes long "multi-byte size" > > The total size of the resulting encoding equals to the size of the BerElement > structure buffer plus one byte. This causes the function returns indicating that > more data are needed, but leaves the read-pointer pointing right at the end of > the buffer, which is not permitted. > > Subsequent calls to the function result in an assertion failure: > > assert( 0 ); /* ber structure is messed up ?*/ > > Example Exploitation: > > > slapd -h ldap:// -d511& > ... > > xxd packet > 0000000: ffff ff00 8441 4243 44 .....ABCD > > nc localhost 389< packet > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs