openldap-devel November 2009

openldap-devel@openldap.org

14 participants
21 discussions

Re: RE24 (2.4.20) testing call #3
by Gavin Henry 20 Nov '09

20 Nov '09

----- "Dieter Kluenter" <dieter(a)dkluenter.de> wrote: > Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > > > A few new changes, please re-sync and test. Thanks! Hopefully > this > > will be the last of it. In particular, watch test050 please. ;) > > Success, x86_64, openSUSE-11.1 +1 for i386 Fedora 11. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

forcing valgrind dumps
by Hallvard B Furuseth 19 Nov '09

19 Nov '09

Here is a patch to force valgrind to dump memory leaks or all allocations while running. Next we need a patch to filter old allocations out from new one, leaving recent allocations. Dunno if it belongs in the source code or not... IIRC we do have #ifdefs for some external malloc debug stuff already, but I didn't find that now:-( Index: servers/slapd/daemon.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/daemon.c,v retrieving revision 1.442 diff -u -2 -r1.442 daemon.c --- servers/slapd/daemon.c 13 Nov 2009 22:48:51 -0000 1.442 +++ servers/slapd/daemon.c 18 Nov 2009 23:18:29 -0000 @@ -36,4 +36,22 @@ #include <ac/unistd.h> +#ifdef USE_VALGRIND +/* + * When running under valgrind, make kill -USR1 force a leak/alloc dump + * to stderr, in addition to its usual "wake listener" function. + * After SIGUSR1 there will also be a dump before shutdown. + * + * Usage: + * valgrind --leak-check=yes --show-reachable=yes slapd -d0 2>slapd.out & + * kill -USR1 <slapd or valgrind process> + * + * For recent leaks/allocs only, do kill -USR1 after startup and again + * sometime later. Then filter out from the 2nd dump the occurrences of + * allocs from the 1st dump. + */ +#include <ac/signal.h> +#include <valgrind/memcheck.h> +#endif /* USE_VALGRIND */ + #include "slap.h" #include "ldap_pvt_thread.h" @@ -664,4 +682,25 @@ #endif /* ! epoll && ! /dev/poll */ +#ifdef USE_VALGRIND +static sig_atomic_t slap_valgrind_requested = 0; +#define slap_valgrind_request() ((void) (slap_valgrind_requested = 2)) +static void +slap_valgrind_check( int when, const char *msg ) +{ + if ( slap_valgrind_requested >= when && RUNNING_ON_VALGRIND ) { + Debug( LDAP_DEBUG_TRACE, "Valgrind dump %s\n", msg, 0, 0 ); + /* Needed for terminator between valgrind -q dumps */ + VALGRIND_PRINTF( "==> Valgrind dump %s\n", msg ); + VALGRIND_DO_LEAK_CHECK; + VALGRIND_PRINTF( "<== Valgrind dump %s\n", msg ); + slap_valgrind_requested = 1; + } +} + +#else /* !USE_VALGRIND */ +#define slap_valgrind_check(when, msg) ((void) 0) +#define slap_valgrind_request() ((void) 0) +#endif /* USE_VALGRIND */ + #ifdef HAVE_SLP /* @@ -2308,4 +2347,6 @@ struct re_s* rtask; + slap_valgrind_check( 2, "while running" ); + now = slap_get_time(); @@ -2760,4 +2801,6 @@ } + slap_valgrind_check( 1, "before shutdown" ); + if ( slapd_gentle_shutdown != 2 ) close_listeners ( 0 ); @@ -2942,4 +2985,6 @@ int save_errno = errno; + slap_valgrind_request(); + WAKE_LISTENER(1);

2 2

Re: commit: ldap/servers/slapd connection.c slap.h
by Hallvard B Furuseth 19 Nov '09

19 Nov '09

hyc(a)OpenLDAP.org writes: > slap.h 1.881 -> 1.882 > >- int c_struct_state; /* structure management state */ >- int c_conn_state; /* connection state */ >+ enum sc_struct_state c_struct_state; /* structure management state */ >+ enum sc_conn_state c_conn_state; /* connection state */ Note that this is potentially a binary incompatible change. I'm never clear on how hard we try to avoid those in slapd... These enum types need not take more than 1 byte each. (OTOH enum constants declared _in_ the enum have type int.) -- Hallvard

2 1

RE24 (2.4.20) testing call #2
by Quanah Gibson-Mount 19 Nov '09

19 Nov '09

Please test current RE24 CVS. Several issues identified in the first round have been resolved. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 4

Please test RE24 for 5.0.20 candidate
by Quanah Gibson-Mount 19 Nov '09

19 Nov '09

Please test current RE24, thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

5 5

contrib/slapd-modules/passwd/sha2
by Michael Ströder 18 Nov '09

18 Nov '09

HI! Is there any chance that contrib/slapd-modules/passwd/sha2 will make it to being a standard feature like e.g. password scheme {SSHA} within 2.4 release series? Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

1 0

contextCSN interaction between syncrepl and syncprov
by Rein Tollevik 17 Nov '09

17 Nov '09

The remaining errors and race condition that test058 demonstrates cannot be solved unless syncrepl is changed to always store the contextCSN in the suffix of the database where it is configured, not the suffix of its glue database as it does today. Assuming serverID 0 is reserved for the single master case, syncrepl and syncprov can in that case only be configured within the same database context if syncprov is a pure forwarding server I.e, it will not update any CSN value and syncrepl have no need to fetch any values from it. In the multi-master case it is only the contextCSN whose SID matches the current serverID that syncprov maintains, the other are all received by syncrepl. So, the only time syncrepl should need an updated CSN from syncprov is when it is about to present it to its peer, i.e when it initiates a refresh phase. Actually, a race condition that would render the state of the database undetermined could occur if syncrepl fetches an updated CSN from syncprov during the initial refresh phase. So, it should be sufficient to read the contextCSN values from the database before a new refresh phase is initiated, independent of whether syncprov is in use or not. Syncrepl will receive updates to the contextCSN value with its own SID from its peers, at least with ITS#5972 and ITS#5973 in place. I.e, the normal ignoring of updates tagged with a too old contextCSN value will continue to work. It should also be safe to ignore all updates tagged with a contextCSN or entryCSN value whose SID is the current servers non-zero serverID, provided a complete refresh cycle is known to have taken place. I.e, when a contextCSN value with the current non-zero serverID was read from the database before the refresh phase started, or after the persistent phase have been entered. The state of the database will be undetermined unless an initial refresh (i.e starting from an empty database or CSN set) have been run to completion. I cannot see how this can be avoided, and as far as I know it is so now too. It might be worth mentioning in the doc. though (unless it already is). Syncprov must continue to monitor the contextCSN updates from syncrepl. When it receives updates destined for the suffix of the database it itself is configured it must replace any CSN value whose SID matches its own non-zero serverID with the value it manages itself (which should be greater or equal to the value syncrepl tried to store unless something is seriously wrong). Updates to "foreign" contextCSN values (i.e those with a SID not matching the current non-zero serverID) should be imported into the set of contextCSN values syncprov itself maintain. Syncprov could also short-circuit the contextCSN update and delay it to its own checkpoint. I'm not sure what effect the checkpoint feature have today when syncrepl constantly updates the contextCSN.. Syncprov must, when syncrepl updates the contextCSN in the suffix of a subordinate DB, update its own knowledge of the "foreign" CSNs to be the *lowest* CSN with any given SID stored in all the subordinate DBs (where syncrepl is configured). And no update must take place unless a contextCSN value have been stored in *all* the syncrepl-enabled subordinate DBs. Any values matching the current non-zero serverID should be updated in this case too, but a new value should probably not be inserted. These changes should (unless I'm completely lost that is..) create a cleaner interface between syncrepl and syncprov without harming the current multi-master configurations, and make asymmetric multiple masters configurations like the one in test058 work. Comments please? Rein

2 4

Re: commit: ldap/servers/slapd bconfig.c
by Ralf Haferkamp 15 Nov '09

15 Nov '09

Am Donnerstag 05 November 2009 15:38:03 schrieb ralf(a)openldap.org: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > bconfig.c 1.395 -> 1.396 > > Log Message: > Initialize ConfigArgs before calling config_del_vals (ITS#6363) Hm, after looking at this again I wonder if it would be better to move the c->argv[] initialization into config_del_vals(). To avoid the duplicated code that this patch created. -- Ralf

2 1

Re: TLS renegotiation
by Howard Chu 12 Nov '09

12 Nov '09

William A. Rowe Jr. wrote: > Howard Chu wrote: >> Emmanuel Lecharny wrote: >>> Wondering if we (ApacheDS) can be a possible target, assuming that we >>> are Java based. Any idea ? >> >> I think Kurt's post already outlined the points of exposure but just to recap: >> >> Renegotiation for privilege escalation is only a threat if the server >> automatically and implicitly uses the client's certificate for authentication. > > That is fine as it goes. > > But there are other factors involved in the TLS renegotiation sequence, not just > simply requesting client certificate authentication, and none of that matters > because the MITM has already injected their self into this stream. > > Unless all other forms of negotation are rejected outright, the problem remains. Most of it is a non-problem; the MITM cannot inject any operations that will run under the client's credentials. Nor can it eavesdrop on the encrypted traffic or tamper with it once underway. It's a lot of work for no gain. > I'm more interested to know if anyone has looked at the question of which clients > or servers are using renegotiation features (remember tlsv1_alert import nonsense?) > or if openldap works just fine with OpenSSL 0.9.8l (renegotiation-crippled) provider. As I already said here http://www.openldap.org/lists/openldap-software/200911/msg00102.html OpenSSL 0.9.8l is broken, renegotiation requests will hang the connection. -- -- 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: TLS renegotiation
by Howard Chu 12 Nov '09

12 Nov '09

Emmanuel Lecharny wrote: > Howard Chu wrote: >> Ludovic Poitou wrote: >> >>> Howard, >>> >>> Our security expert at Sun consider that the attack could be applied to >>> LDAP, although it will be more complex to achieve for all the good >>> reasons you've outline (session-oriented, with explicit authentication >>> attached to a session, and is a record-oriented ASN.1 encoded protocol >>> with precisely defined message structure). >>> The renegotiation in the attack is as far as I understand, driven by the >>> man in the middle, and so even though OpenLDAP slapd never request the >>> renegociation, it is still subject to the attack. >> Hi Ludo, thanks for the note. Kurt and I were discussing this offline and he >> has suggested a possible attack as well. I'm still not convinced of the >> details but we'll continue to investigate. >> > Wondering if we (ApacheDS) can be a possible target, assuming that we > are Java based. Any idea ? I think Kurt's post already outlined the points of exposure but just to recap: Renegotiation for privilege escalation is only a threat if the server automatically and implicitly uses the client's certificate for authentication. An LDAPv3-compliant server should be requiring the use of SASL/EXTERNAL Bind for certificate-based authentication, so if your server is actually compliant then there is no privilege escalation threat. If your server does implicit certificate authentication, then you have a vulnerability here. OpenLDAP slapd is not vulnerable to this particular threat. While our current TLS code allows renegotiation, only the certificate used in the first TLS handshake (if any) is ever parsed by slapd. So at worst, an MITM can impose its own certificate credentials onto a client's session. Aside from causing the client's requests to fail due to insufficient privileges, I don't see what this accomplishes. (In fact it leads me to wonder if we can leverage this as a feature, when proxying encrypted sessions. But that's for another day...) Given the inability of an MITM to do anything useful to the authentication state, I don't consider the request-injection aspect worthy of any further concern. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel November 2009