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. > My 2 cents. > > Ludovic. > > On Nov 8, 2009, at 11:04 AM, Howard Chu wrote: > >> Dieter Kluenter wrote: >>> Hi, >>> I just wonder weather LDAP and in particular OpenLDAP is affected by >>> TLS client auth renegotiation, as described >>> http://extendedsubset.com/?p=8 >>> and the fix >>> http://isc.sans.org/diary.html?storyid=7543 >> >> No. These attacks are specific to HTTP; they are effective because HTTP is >> inherently stateless, lacks an explicit Authentication operation in its >> protocol spec, and is a line-oriented plaintext protocol with mostly >> ad hoc >> structure. Since LDAP is inherently session-oriented, with explicit >> authentication attached to a session, and is a record-oriented ASN.1 >> encoded >> protocol with precisely defined message structure, this stuff doesn't >> apply. >> >> There may be other plaintext protocols that are similarly affected, >> though I >> tend to doubt it. The majority of other useful, widely deployed plaintext >> protocols are session-oriented... >> >> The PDF document outlines 3 vulnerability scenarios. >> >> In the first case, the problem is that an HTTP server might be serving >> documents from multiple security domains, and some may require certificate >> authentication while others don't, and the server won't know what is >> required >> until it has parsed the HTTP request. Because HTTP is stateless and >> the client >> has simply issued a GET request, the certificate authentication has to >> occur >> implicitly via a renegotiation of TLS session and be applied >> retroactively to >> the request. >> >> LDAP never applies authentication retroactively to a session. In LDAP, >> while >> you are allowed to renegotiate TLS in the middle of an LDAP session, >> there is >> no actual reason to do so, and OpenLDAP slapd certainly never requests >> it. If >> a client were to do a renegotiate to provide a new client cert, it still >> wouldn't affect the LDAP session until a new LDAP Bind with >> SASL/EXTERNAL was >> performed, and LDAP Bind is a hard delimiter - nothing sent before the >> Bind >> request can cause a response after the request. No session state can >> straddle >> a Bind. Therefore you can't perform privilege escalation attacks like >> this in >> LDAP. >> >> In the second case, differing crypto requirements - in OpenLDAP this can't >> arise because cipher suite selection is global to the server, not >> dependent on >> request context. ACLs may require a particular strength before >> allowing access >> to a resource, but slapd simply denies the request in that case, it >> doesn't >> try to automagically renegotiate stronger crypto with the client. >> (Note that >> the PDF recommends making cipher suite configuration global in the >> HTTP server >> as well, to mitigate this attack. Duh.) >> >> As for the Man in the Middle aspect, this vulnerability exists because >> HTTP is >> a simple text line-oriented protocol, without real record boundaries. >> LDAP is >> based on ASN.1, where each message has an explicit length encoded in the >> protocol. You can't just pre-inject a bunch of data and splice a valid >> LDAP >> request onto the end of it, the result will not be a valid LDAP >> request. slapd >> will get a parsing error when decoding such an attempt, and will >> simply drop >> the connection as it does for any improperly encoded messages it receives. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
