openldap-devel

openldap-devel@openldap.org

1416 discussions

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

RE24: Decoding error when querying MS AD
by Michael Ströder 04 Nov '09

04 Nov '09

HI! Something's screwed up in BER decoding of RE24 now. I get a LDAP_DECODING_ERROR but it used to work with former versions. I guess this is related to the recent changes to liblber. Ciao, Michael.

2 3

slapd tcp buffers support (ITS#6234)
by Quanah Gibson-Mount 30 Oct '09

30 Oct '09

This was added to OpenLDAP 2.4.18 release, however the ifdef about DEVEL was never removed. The intent was to make it usable with 2.4.18 and later. I'm guessing the ifdef should be removed now in HEAD, at which point I'll sync it to RE24? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Fwd: LLVMdev Digest, Vol 64, Issue 54
by Howard Chu 30 Oct '09

30 Oct '09

I was just thinking about trying out LLVM, looks like someone already got there. -------- Original Message -------- Date: Fri, 30 Oct 2009 17:40:43 +0800 From: Nan Zhu <zhunansjtu(a)gmail.com> Subject: [LLVMdev] I have built a whole-program bitcode file for openldap-2.19 To: llvmdev(a)cs.uiuc.edu Hi,all I have written a wrapper which includes gcc/g++,ld and llvm counterparts, it invokes native or llvm compiler and linker according to the options it receives,after I replace the native tools with my wrapper in libtool script, I just typed like this make CC=wrapper AC_CFLAGS=-emit-llvm then I got a bc file of slapd and other tools in clients directory The accessory is the whole-program bitcode file of slapd (My platform is Fedora11 x86_64+E6300) the method can also be applied to many GNU projects but there may be some other problems when I treat to BIND,I'm checking it.. Thank you

1 0

Re: commit: ldap/libraries/libldap sasl.c
by Hallvard B Furuseth 27 Oct '09

27 Oct '09

Still seems wrong: Caller passes len=500, generic_sb_sasl_write() returns 0 or -1 with LDAP_PVT_SASL_PARTIAL_WRITE, caller collects 300 more bytes and passes len=800, then generic_sb_sasl_write() ignores not 500 but 800 bytes and tells caller that they were all written. Either make p->flags a ber_slen_t with the number of incoming bytes to ignore, or after p->ops->encode() = success, write() = <partial write or non-fatal error> return len-1 with with LDAP_PVT_SASL_PARTIAL_WRITE. -- Hallvard

2 1

Re: small project
by Dmitry Kolesov 26 Oct '09

26 Oct '09

Hello. Could you tell me more about add LDIFv2 (XML) support to ldapadd/modify and slapadd? -Dmitry > I would suggest starting by adding import support to ldapadd/modify > and slapadd, then may adding export support to ldapsearch and slapdump > (using some sort of content detection to determine whether or not to > use xml-value-spec or not). > > -- Kurt

1 0

todo items, still some are available?
by kalyanasundaram s 24 Oct '09

24 Oct '09

All the items in the todo list are up for grabs? I guess some are already done like the rfc 2891. -kalyan

2 1

Distributed ppolicy state
by Howard Chu 23 Oct '09

23 Oct '09

One of the major concerns I still have with password policy is the issue of the overhead involved in maintaining so many policy state variables for authentication failure / lockout tracking. It turns what would otherwise be pure read operations into writes, which is already troublesome for some cases. But in the context of replication, the problem can be multiplied by the number of replicas in use. Avoiding this write magnification effect is one of the reasons the initial versions of the ppolicy overlay explicitly prevented its state updates from being replicated. Replicating these state updates for every authentication request simply won't scale. Unfortunately the braindead account lockout policy really doesn't work well without this sort of state information. The problem is not much different from the scaling issues we have to deal with in making code run well on multiprocessor / multicore machines. Having developed effective solutions to those problems, we ought to be able to apply the same thinking to this as well. The key to excellent scaling is the so-called "shared-nothing" approach, where every processor just uses its own local resources and never has to synchronize with ( == wait for) any other processor, but for the most part it's a design ideal, not something you can do perfectly in practice. However, we have some recent examples in the slapd code where we've been able to use this approach to good effect. In the connection manager, we used to handle monitoring/counter information (number of ops, type of ops, etc) in a single counter, which required a lot of locking overhead to update. We now use an array of counters per thread, and each thread can update its own counters for free, completely eliminating the locking overhead. The trick is in recognizing that this type of info is written far more often than it is read, so optimizing the update case is far more important than optimizing the query case. When someone tries to read the counters that are exposed in back-monitor, then we simply iterate across the arrays and tally up the counters then. Since there's no particular requirement that all the counters be read in the same instant in time, all of these reads/updates can be performed without locking, so again we get it for free, no synchronization overhead at all. So, it should now be obvious where we should go with the replication issue... Ideally, you want password policy enforcement rules that don't even need global state at all. IMO, the best approach is still to keep policy state private to each DSA, and this still makes sense for DSAs that are topologically remote. E.g., assume you have a pair of servers, each in two separate cities. It's unlikely that a login attempt on one server will be in any way connected to a simultaneous login attempt on the other server. And in the face of bot attack, the rate of logins will probably be high enough to swamp the channel between the two servers, resulting in queueing delays that ultimately aggregate several of the updates on the attacked server into just a single update on the remote server. (E.g., N separate failure updates on one server will coalesce into a single update on the remote server.) Therefore, most of the time it's pointless for each server to try to immediately update the other with login failure info. In the case of a local, load-balanced cluster of replicas, where the network latency between DSAs is very low, the natural coalescing of updates may not occur as often. Still, it would be better if the updates didn't happen at all. And in such an environment, where the DSAs are so close together that latency is low, distributing reads is still cheaper than distributing writes. So, the correct way to implement this global state is to keep it distributed separately during writes, and collect it during reads. I'm looking for a way to express this in the schema and in the ppolicy draft, but I'm not sure how just yet. It strikes me that X.500 probably already has a type of distributed/collective attribute but I haven't looked yet. Also I think we can take this a step further, but haven't thought it through all the way yet. If you typically have login failures coming from a single client, it should be sufficient to always route that client's requests to the same DSA, and have all of its failure tracking done locally/privately on that DSA. At the other end, if you have an attack mounted by a number of separate machines, it's not clear that you must necessarily collect the state from every DSA on every authentication request. E.g., if you're setting a lockout based on the number of login failures, once the failure counter on a single DSA reaches the lockout threshold, it doesn't matter any more what the failure counter is on any other DSA, so that DSA no longer needs to look for the values on any other node. If a client comes along and does a search to retrieve the policy state, e.g. looking for the last successful login or the last failure, then you want whatever DSA receives the request to broadcast the search to all the other DSAs and collate the results for the client by default. (Note that simple aggregation only works for multivalued attributes; for single-valued attributes like pwdLastSuccess you have to know to pick the most recent value.) And probably you should be able to specify a control (like ManageDSAit) to disable this automatic broadcast and only retrieve the value from a single DSA. I realize that the points listed above about login attacks miss several attack scenarios. I think more of the scenarios need to be outlined and analyzed before moving forward with any recommendations on lockout behavior; the internet today is pretty different from when these lockout mechanisms were first designed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel