July 2009 - openldap-bugs

Re: (ITS#6239) ldap_pvt_tls_check_hostname() may be vulnerable

by hyc＠symas.com

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: any > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > Our chkhost implementation for OpenSSL does a simple strcasecmp on the name > obtained from the certificate CN; if the CN has an embedded NUL it is possible > for this check to be spoofed. This is now fixed in HEAD. > > Our chkhost implementation for GnuTLS is not vulnerable. > > We didn't write a chkhost implementation for MozNSS, we just use the default one > they provide. Inspecting their code shows that their default checker is also > vulnerable. I will be writing a replacement for libldap shortly. All fixed in HEAD/RE24. Surprisingly, the GnuTLS API got this one right. So did OpenSSL (we just botched our use of their APIs). But the MozNSS APIs all discard the length info of the data instead of returning it, so we had to reimplement some of their basic name-handling code in libldap. Probably should have just done all of this using DER and liblber too, like the other cert parsing code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 2 months

1
0
0 / 0

(ITS#6239) ldap_pvt_tls_check_hostname() may be vulnerable

by hyc＠OpenLDAP.org

Full_Name: Howard Chu Version: any OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Our chkhost implementation for OpenSSL does a simple strcasecmp on the name obtained from the certificate CN; if the CN has an embedded NUL it is possible for this check to be spoofed. This is now fixed in HEAD. Our chkhost implementation for GnuTLS is not vulnerable. We didn't write a chkhost implementation for MozNSS, we just use the default one they provide. Inspecting their code shows that their default checker is also vulnerable. I will be writing a replacement for libldap shortly.

14 years, 2 months

1
0
0 / 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind

by michael＠stroeder.com

jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. Detecting unused accounts can also somewhat achieved by using slapo-accesslog with configuration directive "logops session". Still I see some value for such an simple overlay. > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. Things to consider: Is this attribute supposed to be replicated? How about adding configuration paramters so you can specify 1. the attribute type used and 2. the datetime format. This could be handy in situations where you want to mimique the behaviour of other LDAP servers. Ciao, Michael.

14 years, 2 months

1
0
0 / 0

(ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind

by jonathan＠phillipoux.net

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz Submission from: (NULL) (82.67.204.30) Hi, Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that intercepts successful binds and records the current timestamp in an attribute named "bindTimestamp" in the bound-to entry. It's original use-case is to detect unused accounts. A configuration parameter (olcLastBindPrecision) allows to set a minimum precision for the timestamp (ie, don't update the timestamp unless it's older than <n> seconds). This avoids a performance hit from many unnecessary writes in case there are many binds per minute/hour/day/week/etc. Of course, the behaviour this overlay implements is not described in any RFC, or other. However, it closely resembles some of the functionality from the password policy overlay, and similar functionality already exists in other LDAP servers. I post it here in the hope that it may serve others, and in case the OpenLDAP wishes to include it in one form or another. I would most appreciate any comments or feedback. Regards, Jonathan PS: please note that the OIDs used are not registered, but used temporarily. I do not currently have access to a registered OID to use.

14 years, 2 months

1
0
0 / 0

Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST

by masarati＠aero.polimi.it

evaristojosec(a)yahoo.es wrote: > Full_Name: Evaristo Camarero > Version: 2.4.x > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.20) > > > > Hi, > > Working with slapd under heavy load it could be interesting to have TCP buffers > size configurable at slapd application level instead of getting default OS > values. > > Some fast modifications in daemon.c file to achieve a hardcoded value for the > sender buffer are: > > int buf_size = 1572864; /* 1.5 Mb */ > rc =setsockopt ( s, SOL_SOCKET, SO_SNDBUF, (int*)&buf_size, > sizeof(buf_size)); > if(rc==-1) { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): " > "setsockopt(SO_SNDBUF) failed errno=%d (%s)\n", > (long) l.sl_sd, err, sock_errstr(err) ); > } else { > Debug( LDAP_DEBUG_ANY, "slapd(%ld): setsockopt(SO_SNDBUF) to %d\n", > (long) l.sl_sd, buf_size, 0); > } Since you use Linux, you could try the kernel's tcp autotuning capabilities described in tcp(7) (other informative links are <http://fasterdata.es.net/TCP-tuning/linux.html>, <http://www.kernelfaq.com/2007/11/tcp-auto-tuning.html>). Of course, the possibility to manually enforce the size of the buffer may be useful in some cases, so a specific configuration option may deserve consideration. p.

14 years, 2 months

1
0
0 / 0

Re: (ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)

by mkassawara＠gmail.com

The configure script can't find the BDB headers/libraries in the typical places. Either install them to a typical place seen by the preprocessor/linker (e.g., /usr/include, /usr/lib, /usr/local/ include, /usr/local/lib ...) or set the CPPFLAGS and LDFLAGS environment variables appropriately before running the configure script. If you plan to install OpenLDAP to a custom location, consider using "crle" to add the necessary library path(s) to the runtime linking environment. Also, to prevent another issue down the road, make sure you apply the Oracle patches to BDB 4.7.25 before building it. This is not an ITS... you should use openldap-technical for future correspondence on this issue. On Jul 29, 2009, at 3:09 PM, mark.liu(a)nyu.edu wrote: > Full_Name: Mark Liu > Version: 2.4.16 > OS: Sun Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.122.149.115) > > > I am trying to install openLDAP on Solaris 10. Whenever I tried to > configure > openLDAP, it would give the following message: > > checking db.h usability... no > checking db.h presence... no > checking for db.h... no > configure: error: BDB/HDB: BerkeleyDB not available > > The install would stop there. I thought it might be require a > different version > of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. > OpenLDAP > produced the same result for both instances of BerkeleyDB. > > What do i need to do to get pass this? Thanks! >

14 years, 2 months

1
0
0 / 0

(ITS#6235) Installing openLDAP on Solaris 10 (Berkeley DB issue)

by mark.liu＠nyu.edu

Full_Name: Mark Liu Version: 2.4.16 OS: Sun Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.122.149.115) I am trying to install openLDAP on Solaris 10. Whenever I tried to configure openLDAP, it would give the following message: checking db.h usability... no checking db.h presence... no checking for db.h... no configure: error: BDB/HDB: BerkeleyDB not available The install would stop there. I thought it might be require a different version of BerkeleyDB, I downloaded both BerkeleyDB 4.7.25 and 4.6.21. OpenLDAP produced the same result for both instances of BerkeleyDB. What do i need to do to get pass this? Thanks!

14 years, 2 months

1
0
0 / 0

Re: (ITS#6225) GSSAPI support for client library (fixes)

by mikbec＠web.de

hyc(a)symas.com wrote: > mimir(a)samba.org wrote: >> Full_Name: Rafal Szczesniak >> Version: Stable (2.4.16) >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-bugfix.diff >> Submission from: (NULL) (67.51.54.234) >> >> >> This is a bugfix patch for OpenLDAP's gssapi support. >> > One of these patches appears to duplicate ITS#6092. As the original author of > this code, could you also take a look at #6091 and #6093? > Yes, I think this patch tries to resolve the same problem like #6093 but with a different approach. And after some discussion with Hallvard B Furuseth about the guess_service_principal() string problem (#6223) I have sent a all-in-one-patch which results in #6110. best regards mike

14 years, 2 months

1
0
0 / 0

Re: (ITS#6215) liblber problems

by h.b.furuseth＠usit.uio.no

Fixing this, and some other problems: - decode.c incorrectly treats length octet 0x80 (indefinite-length) as long length = 0. Fixing to returning an error. - Overly complex and inefficient code, in particular encode.c. Rewriting. Removing struct seqorset and related allocations. - Missing overflow/max-size checks. - ber_scanf() *must* clean up properly on error, as the code notes. Currently it can crash when reading malformed elements. Both encode.c and decode.c mostly access the Ber data "properly" via ber_write()/ber_read() but sometimes accesses the buffer directly. Can clean up and speed up at the same time by collecting that in fewer places. Side effects: - Dropping ber_write(,,,nonzero) support. Any callers likey need to use BerElement.ber_sos_ptr/ber_sos_inner, the struct seqorset replacement. - Dropping ber_log_sos_dump() and ber_sos_dump(), leaving behind stubs. They'd need a new ber parameter to work. Other matters - questions: - decode.c is quite lax about what it accepts. Should we tighten that when feasible, or remain "liberal in what we accept"? E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and wrong CONSTRUCTED/PRIMITIVE encoding bit. - encode.c willingly stores broken identifier octets if passed an invalid tag, e.g. a single octet with low bits 0x1F implying long tag format. I'm inclined to leave that alone, caller's responsibility. -- Hallvard

14 years, 2 months

1
0
0 / 0

Re: (ITS#6232) OpenLDAP 2.4.17 fails to compile with --with-tls=gnutls

by steffen＠hauihau.de

Dear Howard, please have a look at http://bugs.gentoo.org/show_bug.cgi?id=233633 . The provided patch in the Debian bug tracker does not fix the compiling issue of passwd.c as the defines and typedefs are inserted *after* the first occurrence of "des_key". I've modified this patch, and it's already included in gentoo's ebuild for OpenLDAP 2.4.17. I don't know if I'm authorized to contribute it to the ITS, as I've only modified the original patch. I would do it of course, if 'm allowed to, since there is no employer, who would prevent me to do it, as I'm doing it in my freetime.

14 years, 2 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2009