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
-Dieter
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,
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.
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/
--- Ludovic Poitou Sun Microsystems Inc. OpenDS Community Manager Directory Services http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France
Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest
Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 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 ?
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 ?
Kurt will be posting a more extensive message on the topic later. I suppose your degree of exposure depends on certain details of your implementation of ldaps:// and/or StartTLS. In the case of OpenLDAP, it is impossible for a MITM to perform a privilege escalation with this attack. There are other things an attacker could do, such as nullifying a particular client request. It amounts to being able to DOS a specific client or a specific user, which is interesting and annoying, but also highly traceable...
I've now posted my preliminary report on the general impact of TLS renegotiation on LDAP to the ldapext@ietf.org list, for initial discussion there. A final report will be made available later, likely posted to ldap@umich.edu.
This message is available in our local archive of this list: http://www.openldap.org/lists/ietf-ldapext/200911/msg00000.html
Howard has already made a brief statement here regarding impact upon OpenLDAP Software on this list. In short summary, only the "milder issue" applies to OpenLDAP Software (and seems to a very minor concern). Clients can mitigate this issue as discussed in the report. Servers can mitigate this issue by disabling TLS renegotiations within their TLS library. Disabling TLS renegotiations in the server has side effects which might not be desirable in certain deployments.
-- Kurt
Kurt Zeilenga wrote:
I've now posted my preliminary report on the general impact of TLS renegotiation on LDAP to the ldapext@ietf.org list, for initial discussion there. A final report will be made available later, likely posted to ldap@umich.edu.
This message is available in our local archive of this list: http://www.openldap.org/lists/ietf-ldapext/200911/msg00000.html
Howard has already made a brief statement here regarding impact upon OpenLDAP Software on this list. In short summary, only the "milder issue" applies to OpenLDAP Software (and seems to a very minor concern). Clients can mitigate this issue as discussed in the report. Servers can mitigate this issue by disabling TLS renegotiations within their TLS library. Disabling TLS renegotiations in the server has side effects which might not be desirable in certain deployments.
OpenSSL 0.8.9l was quickly released in response to this attack. It is supposed to disable TLS renegotiation support, but it has a number of bugs. Instead of cleanly closing the session when a reneg occurs, it hangs. I suggest that people hold off another couple days before deploying a TLS reneg fix. At least for OpenLDAP, since in this case the cure is worse than the actual problem.
http://groups.google.com/group/mailing.openssl.dev/browse_thread/thread/4c36...
openldap-software@openldap.org
-
Dieter Kluenter -
Emmanuel Lecharny -
Howard Chu -
Kurt Zeilenga -
Ludovic Poitou