From Kurt.Zeilenga@isode.com Tue Nov 10 23:36:10 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329A73A6A24 for ; Tue, 10 Nov 2009 23:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ufxvHusqMeE8 for ; Tue, 10 Nov 2009 23:36:09 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CDDE63A6C2C for ; Tue, 10 Nov 2009 23:36:08 -0800 (PST) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id for ; Wed, 11 Nov 2009 07:36:35 +0000 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga Date: Tue, 10 Nov 2009 23:35:51 -0800 Message-Id: To: ldapext X-Mailer: Apple Mail (2.1076) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Subject: [ldapext] LDAP and the TLS renegotiation vulnerabilities X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 07:36:10 -0000 Over the last few days I took some time to study into how LDAP is impacted by the TLS renegotiation vulnerability. This note discusses my preliminary findings. Suggested reading: http://extendedsubset.com/?p=8 http://extendedsubset.com/Renegotiating_TLS.pdf http://www.ietf.org/id/draft-rescorla-tls-renegotiation-00.txt Discussion: First, disabling TLS renegotiations in the server prevents all of these attacks discussed below. Unfortunately, doing this will have some negative impacts. But it might be best short term solution, but it's not without some issues and may be inappropriate for some deployments (such as those relying on long-lived TLS protected LDAP sessions). Assuming TLS renegotiations are enabled in the server.... The most significant impact LDAP is in servers supporting the non- standard "implicit bind" (or "auto bind") feature. This feature, which dates back to LDAPv2 and SSL days, provides for use of client certificates to establish the client's identity without a requirement to perform a LDAP Bind operation. That is, the client would simply assert its certificate as part of the TLS handshake and the server would, if the certificate was acceptable, process all future operations as the identity it associates with the certificate. The attacker can use the TLS renegotiation vulnerability to cause the server to process any request, including update requests, as the identity associated with the client's certificate. Aside from disabling TLS renegotiating in the server, disabling LDAP 'implicit bind' feature prevents this. There is little excuse for clients not to be doing StartTLS + LDAP SASL EXTERNAL Bind. A milder impact to LDAP is in clients which do: StartTLS ++ establish TLS, assert certificate + LDAP SASL EXTERNAL Bind + subsequent LDAP requests Because the LDAP SASL EXTERNAL BIND requests tend to have a predictable encoding and the TLS vulnerabilities allow for prefixing arbitrary data, it is possible for the attacker to construct an LDAP Simple "anonymous" Bind which eclipses the LDAP SASL EXTERNAL BIND and, hence, causes the subsequent LDAP requests to be processed "anonymously" instead of as the identity associated with the client's certificate. This could lead to the client thinking some resources were absent when they actually exist. There are variants of this scenario but this seems to be the most interesting. Aside from disabling TLS renegotiating in the server, this particular attack can be mitigated by the client by initiating and completing LDAP search operation, such as as a read of the Root DSE, after the TLS handshake but before initiating the LDAP SASL EXTERNAL Bind request. There may well be other possible attacks. Recommendations: Disable TLS renegotiations in the server. Disable 'implicit bind' in the server. Clients should use LDAPv3's StartTLS + SASL EXTERNAL instead. Clients providing client certificates in TLS handshakes might consider doing an LDAP Search before the LDAP SASL EXTERNAL Bind as discussed above. Implement support in clients and servers for the TLS protocol fix (draft-rescorla-tls-renegotiation). Early implementations of this fix in commonly used TLS libraries are already emerging. Summary: The TLS renegotiation vulnerability can be used to mount attacks upon LDAP applications, especially those relying on non-standard LDAP 'implicit' binds. A fix to TLS (draft-rescorla-tls-renegotiation) is in the works and LDAP vendors should start work on supporting it. By following the above recommendations, the impact of the TLS renegotiation issues upon LDAP can be minimized. -- Kurt NOTE: I have purposely left off key details on how to mount such attacks to slow unskilled attackers. From michael@stroeder.com Tue Nov 17 03:16:31 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B14D3A6937 for ; Tue, 17 Nov 2009 03:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DATE_IN_PAST_03_06=0.044, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlOBRFIUwwXo for ; Tue, 17 Nov 2009 03:16:30 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 3EF1D3A68CE for ; Tue, 17 Nov 2009 03:16:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 12A4C4E0D4; Tue, 17 Nov 2009 12:16:15 +0100 (CET) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERInqGE18y15; Tue, 17 Nov 2009 12:16:13 +0100 (CET) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 6CDD44E0B2; Tue, 17 Nov 2009 12:16:10 +0100 (CET) Message-ID: <4B025655.7060104@stroeder.com> Date: Tue, 17 Nov 2009 08:52:53 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Kurt Zeilenga References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ldapext Subject: Re: [ldapext] LDAP and the TLS renegotiation vulnerabilities X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:16:31 -0000 Kurt Zeilenga wrote: > Because the LDAP SASL EXTERNAL BIND requests tend to have a predictable > encoding and the TLS vulnerabilities allow for prefixing arbitrary data, > it is possible for the attacker to construct an LDAP Simple "anonymous" > Bind which eclipses the LDAP SASL EXTERNAL BIND and, hence, causes the > subsequent LDAP requests to be processed "anonymously" instead of as the > identity associated with the client's certificate. This could lead to > the client thinking some resources were absent when they actually > exist. There are variants of this scenario but this seems to be the > most interesting. Aside from disabling TLS renegotiating in the server, > this particular attack can be mitigated by the client by initiating and > completing LDAP search operation, such as as a read of the Root DSE, > after the TLS handshake but before initiating the LDAP SASL EXTERNAL > Bind request. Disclaimer: I'd not claim to fully understand all of it yet. I don't understand how the search request before the SASL bind request helps. Could you please elaborate on that? Wouldn't the use of the LDAP Whoami? Ext. Op. after the SASL bind request also help? (Assuming that the client knows how the server maps the client cert to an identity and the client cross-checks it.) Ciao, Michael.