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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
