Details

    • Type: Task
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M10
    • Fix Version/s: 2.0.0-M19
    • Component/s: ldap
    • Labels:
    • Environment:
      Production

      Description

      How do we disable SSlv3 protocol for apache DS 2.X ?

      As part of poodle remediation we need to disable SSL v3 ASAP in production boxes as the scan showed its vulnerable.

      I cant find any configuration pertaining to the same which I could change .

        Activity

        Hide
        pfm.smits Pierre Smits added a comment -

        This question was also asked in the user ML, See this thread in the archive:
        http://directory.markmail.org/search/?q=poodle#query:poodle%20list%3Aorg.apache.directory.dev+page:1+mid:wxjwdkwtzw7nsmym+state:results

        Did your scan reveal that the ApacheDS 2.0 code has this? Could you provide the result of your scan of the ApacheDS 2.0. implementation?

        Show
        pfm.smits Pierre Smits added a comment - This question was also asked in the user ML, See this thread in the archive: http://directory.markmail.org/search/?q=poodle#query:poodle%20list%3Aorg.apache.directory.dev+page:1+mid:wxjwdkwtzw7nsmym+state:results Did your scan reveal that the ApacheDS 2.0 code has this? Could you provide the result of your scan of the ApacheDS 2.0. implementation?
        Hide
        rakeshacharya RakeshAcharya added a comment -

        We have a tool which scans the servers for the latest Vulnerabilities. So in the server where we have apacheDS only running we got an SSLv3(poodle vulnerability) on the port which is used by apacheds on SSL.

        It doesn't say at the code level but clearly states my LDAPS port is vulnerable. Below is the details it give me in the scan report although its generic.

        THREAT:
        The SSL protocol 3.0 design error, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attacks.
        The target supports SSLv3, which makes it vulnerable to POODLE (Padding Oracle On Downgraded Legacy Encryption), even if it also supports more recent versions of TLS. It's subject to a downgrade attack, in which the attacker tricks the browser into connecting with SSLv3.

        IMPACT:
        An attacker who can take a man-in-the-middle (MitM) position can exploit this vulnerability and gain access to encrypted communication between a client and server.

        When I ran the openssl check it does say SSlv3 as the one being used and available,If server is using TLS then it shouldn't return this,
        I know we use TLS and there is no option for choosing anything else , is there any way to enforce SSLv3 to be disabled at all?

        Am using apache DS 2.0.0.M-10 and java 6 latest update.

        Show
        rakeshacharya RakeshAcharya added a comment - We have a tool which scans the servers for the latest Vulnerabilities. So in the server where we have apacheDS only running we got an SSLv3(poodle vulnerability) on the port which is used by apacheds on SSL. It doesn't say at the code level but clearly states my LDAPS port is vulnerable. Below is the details it give me in the scan report although its generic. THREAT: The SSL protocol 3.0 design error, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attacks. The target supports SSLv3, which makes it vulnerable to POODLE (Padding Oracle On Downgraded Legacy Encryption), even if it also supports more recent versions of TLS. It's subject to a downgrade attack, in which the attacker tricks the browser into connecting with SSLv3. IMPACT: An attacker who can take a man-in-the-middle (MitM) position can exploit this vulnerability and gain access to encrypted communication between a client and server. When I ran the openssl check it does say SSlv3 as the one being used and available,If server is using TLS then it shouldn't return this, I know we use TLS and there is no option for choosing anything else , is there any way to enforce SSLv3 to be disabled at all? Am using apache DS 2.0.0.M-10 and java 6 latest update.
        Hide
        rakeshacharya RakeshAcharya added a comment -

        After examining the code below is what we found

        In the code you use :
        • Java class = org.apache.directory.server.ldap.handlers.ssl.LdapsInitializer
        • Java code =
        o sslCtx = SSLContext.getInstance( "TLS" );

        From previous testing with Tomcat, this value “TLS” means that both SSLv3 and TLSv1.0/1.1/1.2 are supported by the server.

        Can we filter out SSLv3 and force it to be not used at all as it being unsecured.

        Also I disabled SSLv3 from the java control panel which is being used by apacheds and that didn't help either.

        Show
        rakeshacharya RakeshAcharya added a comment - After examining the code below is what we found In the code you use : • Java class = org.apache.directory.server.ldap.handlers.ssl.LdapsInitializer • Java code = o sslCtx = SSLContext.getInstance( "TLS" ); From previous testing with Tomcat, this value “TLS” means that both SSLv3 and TLSv1.0/1.1/1.2 are supported by the server. Can we filter out SSLv3 and force it to be not used at all as it being unsecured. Also I disabled SSLv3 from the java control panel which is being used by apacheds and that didn't help either.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Have you tested with Java 8 ?

        Show
        elecharny Emmanuel Lecharny added a comment - Have you tested with Java 8 ?
        Hide
        rakeshacharya RakeshAcharya added a comment -

        We cant move to Java 8 yet and its not tested in there..

        Show
        rakeshacharya RakeshAcharya added a comment - We cant move to Java 8 yet and its not tested in there..
        Hide
        elecharny Emmanuel Lecharny added a comment -

        I'll going to test a patch in MINA (this is the framework we are depending on for the network layer) to see if I can only enable TLS V1.

        It could take a couple of days to get it tests, as I need to build a new MINA version, then a new ApacheDS version, and I'm currently in a conference. If that fixes the issue, I'll try to cut a new urgent release (ie, it won't require 72h to get it out).

        Show
        elecharny Emmanuel Lecharny added a comment - I'll going to test a patch in MINA (this is the framework we are depending on for the network layer) to see if I can only enable TLS V1. It could take a couple of days to get it tests, as I need to build a new MINA version, then a new ApacheDS version, and I'm currently in a conference. If that fixes the issue, I'll try to cut a new urgent release (ie, it won't require 72h to get it out).
        Hide
        akiran Kiran Ayyagari added a comment -

        Initializing the SslContext with TLSv1 didn't work, looks like this must be fixed in MINA where the SocketFactory is controlled.
        And the relevant CVE from Oracle

        Show
        akiran Kiran Ayyagari added a comment - Initializing the SslContext with TLSv1 didn't work, looks like this must be fixed in MINA where the SocketFactory is controlled. And the relevant CVE from Oracle
        Hide
        akiran Kiran Ayyagari added a comment - - edited

        I confirm that the fix committed at revision 1640461 fixes this issue (see http://svn.apache.org/r1640461).
        You can verify this fix in action using the command

        openssl s_client -connect localhost:10636 -ssl3
        Show
        akiran Kiran Ayyagari added a comment - - edited I confirm that the fix committed at revision 1640461 fixes this issue (see http://svn.apache.org/r1640461 ). You can verify this fix in action using the command openssl s_client -connect localhost:10636 -ssl3
        Hide
        rakeshacharya RakeshAcharya added a comment -

        How do I apply this fix to an existing server, would presume some Config change ? Can you please throw light on the same?

        Show
        rakeshacharya RakeshAcharya added a comment - How do I apply this fix to an existing server, would presume some Config change ? Can you please throw light on the same?
        Hide
        elecharny Emmanuel Lecharny added a comment -

        You can't modify an existing server, it's not a configuration thing (atm).

        The only solution is to build the server from source, and install it.

        I'll cut a release soon, and push the installer on my web site, so that you'll be able to get an installer.

        Show
        elecharny Emmanuel Lecharny added a comment - You can't modify an existing server, it's not a configuration thing (atm). The only solution is to build the server from source, and install it. I'll cut a release soon, and push the installer on my web site, so that you'll be able to get an installer.
        Hide
        rakeshacharya RakeshAcharya added a comment -

        As the system is live in production meaning for the apacheds server in production we will not be able to reinstall or upgrade , so this patch which is a code change I presume cannot be applied without reinstalling.

        The installer will be for new install for this fix, but it will be included in new version of product I presume not with the version we are using 2.0.0-M10

        Show
        rakeshacharya RakeshAcharya added a comment - As the system is live in production meaning for the apacheds server in production we will not be able to reinstall or upgrade , so this patch which is a code change I presume cannot be applied without reinstalling. The installer will be for new install for this fix, but it will be included in new version of product I presume not with the version we are using 2.0.0-M10
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Right.

        And yes, you'll have to integrate a new version in your product.

        Note that if your LDAP server is not visible from the internet (a very basic requirement for a LDAP server), you should be more or less safe, even with the current version.

        Show
        elecharny Emmanuel Lecharny added a comment - Right. And yes, you'll have to integrate a new version in your product. Note that if your LDAP server is not visible from the internet (a very basic requirement for a LDAP server), you should be more or less safe, even with the current version.
        Hide
        rakeshacharya RakeshAcharya added a comment -

        Agreed ..Wanted to weigh options available.

        Show
        rakeshacharya RakeshAcharya added a comment - Agreed ..Wanted to weigh options available.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Actually, I would suggest you use a version that will manage the pb though configuration. The next version will mitigate the SSL issue with a (kind of) ugly patch, where we hard wired the list of protocols we support (and it excludes SSLv3).

        In the very next version, we will move this list in the configuration, so that if, say, TLS v1.1 gets proven to be broken, then one can remove it from the list of protocols.

        Show
        elecharny Emmanuel Lecharny added a comment - Actually, I would suggest you use a version that will manage the pb though configuration. The next version will mitigate the SSL issue with a (kind of) ugly patch, where we hard wired the list of protocols we support (and it excludes SSLv3). In the very next version, we will move this list in the configuration, so that if, say, TLS v1.1 gets proven to be broken, then one can remove it from the list of protocols.
        Hide
        rakeshacharya RakeshAcharya added a comment -

        Which version allows to manage the pb through configuration?

        Show
        rakeshacharya RakeshAcharya added a comment - Which version allows to manage the pb through configuration?
        Hide
        elecharny Emmanuel Lecharny added a comment -

        We are brwing a 2.0.0-M19 atm, which mitigate the pb with hard coded values. M20 or RC1 (we don't know yet if we are going to stop using Milestone...) will contain a configurable protocol list.

        Show
        elecharny Emmanuel Lecharny added a comment - We are brwing a 2.0.0-M19 atm, which mitigate the pb with hard coded values. M20 or RC1 (we don't know yet if we are going to stop using Milestone...) will contain a configurable protocol list.
        Hide
        ccustine Chris Custine added a comment - - edited

        There is probably zero risk of anyone exploiting ApacheDS or LDAP API using POODLE. The downgrade to SSLv3 is merely an enabler of the more complicated attack, which requires injecting and running arbitrary code on the client side. Furthermore, the only useful part of this exploit is decrypting cookies and I am not aware of any cookie exchange as part of the ApacheDS or LDAP API interactions. It takes an average of 256 very specifically engineered requests by the injected code, (ie javascript in a compromised browser) to decrypt a single byte of a cookie. This blog has a very good analysis of the exploit, and the first 4 or 5 paragraphs detail the steps I mention above and should put everyone's minds at ease about this affecting a closed, non-browser, non HTTP server system like ApacheDS and LDAP API: https://www.imperialviolet.org/2014/10/14/poodle.html

        Show
        ccustine Chris Custine added a comment - - edited There is probably zero risk of anyone exploiting ApacheDS or LDAP API using POODLE. The downgrade to SSLv3 is merely an enabler of the more complicated attack, which requires injecting and running arbitrary code on the client side. Furthermore, the only useful part of this exploit is decrypting cookies and I am not aware of any cookie exchange as part of the ApacheDS or LDAP API interactions. It takes an average of 256 very specifically engineered requests by the injected code, (ie javascript in a compromised browser) to decrypt a single byte of a cookie. This blog has a very good analysis of the exploit, and the first 4 or 5 paragraphs detail the steps I mention above and should put everyone's minds at ease about this affecting a closed, non-browser, non HTTP server system like ApacheDS and LDAP API: https://www.imperialviolet.org/2014/10/14/poodle.html
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Thanks Chris. This is probably right, we are most certainly safe.

        OTOH, SSLv3 should have died a decade ago, and it didn't thanks to M$ crappy browsers. So disabling SSLv3 from the server should not harm, and it's not really a costly modification.

        Show
        elecharny Emmanuel Lecharny added a comment - Thanks Chris. This is probably right, we are most certainly safe. OTOH, SSLv3 should have died a decade ago, and it didn't thanks to M$ crappy browsers. So disabling SSLv3 from the server should not harm, and it's not really a costly modification.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Chris, after having read the blog, I do think this is possible to break a PDU using the very same mechanism. In LDAP, that would be quite a burden, but I don't see that as impossible.

        Show
        elecharny Emmanuel Lecharny added a comment - Chris, after having read the blog, I do think this is possible to break a PDU using the very same mechanism. In LDAP, that would be quite a burden, but I don't see that as impossible.
        Hide
        ccustine Chris Custine added a comment -

        No worries, I just wanted to clarify how complicated this exploit would be on a non web browser client and make sure you didn't sacrifice too many late night hours cutting an urgent release. Disabling SSLv3 definitely needs to happen though.

        Show
        ccustine Chris Custine added a comment - No worries, I just wanted to clarify how complicated this exploit would be on a non web browser client and make sure you didn't sacrifice too many late night hours cutting an urgent release. Disabling SSLv3 definitely needs to happen though.
        Hide
        elecharny Emmanuel Lecharny added a comment -
        Show
        elecharny Emmanuel Lecharny added a comment - Fixed with http://svn.apache.org/r1640461

          People

          • Assignee:
            Unassigned
            Reporter:
            rakeshacharya RakeshAcharya
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development