ICS/Lotus (mostly), Linux, Travel, Skiing, Mixology, and Random Musing of Interest

Bill Malchisky


    Find me here…

  • Skype
  • Bleedyellow via Sametime
  • New SSL3 Exploit: The POODLE Is Here and Lifting Its Leg

    Bill Malchisky  October 15 2014 03:12:00 AM
    Fix Update -
    {Update 9, 17 Oct 2014} As companies are working day and night to get a fix for this product, I will keep checking and update you here. Red Hat has a few patches for their various OS releases but they are reported as incomplete and thus not formally released yet. The rest of the post has been updated eight times since initial publication and is pretty static now as we are all in a wait-state until a patch is formally approved and released.
    {Update 10, 17 Oct 2014, 10:01 PM} Starting to see smaller client side packages with POODLE fixes being released.
    {Update 11, 18 Oct 2014 2:43 AM} Server-side partial fix announced
    See the new Impact section below for the two attack permutations, their impact, and risk, plus links to the RHEL version specific package errata in "Fixing the Exploit" at the bottom

    Now we are just waiting for primary exploit fix and client-side browsers to ensure that you have a full and complete solution. This gets you one-third of the way there.

    Here we go again... another blockbuster security exploit with another clever code name is announced. POODLE (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 specifically allows a man-in-the-middle style attack utilizing an SSL3 connection. Once again, Red Hat does a stellar job offering full details on background, technical specifics, and testing. Google's Online Security Blog post is exceedingly terse when contrasting. Here is what you need to know.

    What is It?

    CVE-2014-3566 allows one to decrypt ciphertext using a padding oracle side-channel attack. Look at it this way... this exploit sees every SSL server as a fire hydrant and the man-in-the-middle style POODLE has been drinking water for a long time. The scope is bigger than Shellshock, in my opinion, as it hits any server running SSL 1.0, 2.0, 3.0, and TLS 1.0, plus client-side applications like browsers, but the damage impact appears to be less that one can cause with Shellshock as there is not a remote code execution capability and your system would have some capacity to be productive. To that point, it is (or should be) a high priority for any vendor who hosts SSL and is listed as a high impact
    Red Hat published a Security impact key.


    It is categorized as a High priority and High Severity, which is the third highest of the former and second highest on the latter. So, although this is a nasty exploit, the damage to your systems could be worse. In summary, take care of it, but do not panic.

    Red Hat is making this a top priority and has a KB article (#1232123) on the subject. Excerpts are below. Also, Google's security blog has a couple of paragraphs on this exploit and an eye towards a patch for their products.


    {Update 10 - 17 OCT 2014; new section}
    Two Attack Permutations
    1. Man-in-the-Middle: To quote Red Hat on this exploit's impact, they say, "Exploiting this vulnerability is not easily accomplished. Man-in-the-middle attacks require large amounts of time and resources. While likelihood is low, Red Hat recommends implementing only TLS to avoid flaws in SSL." -- Red Hat via Knowledge Base Article 1232123;
    2. Fallback Attack -- correlated secondary exploit, explained below.

    Red Hat (among others) indicated a TLS Fallback option to let client side applications (e.g. Browsers) to inform a server that they can handle the newer SSL/TLS versions (safer ones). Here is the issue, not all browsers support this capability. So rather than being dropped, a dubious connection attempts to revert to a lower protocol version when the server supports a newer secure protocol version, the unsupported browser flavors allow the insecure protocol connection--creating a POODLE exploit.

    Chromium is the only Linux graphical browser that supports the fallback attack security. Once enabled on a server, the client must support it as well. Firefox and Curl (tui browser) are vulnerable at the time of this writing.

    Additional concerns

    As a workaround, it has been suggested to disable SSL and utilize TLS until a proper SSL patch is released. This of course works for HTTPs client tools that support TLS. If the tool does not understand TLS and you disable SSL, then you have zero security which is much worse than having a POODLE vulnerable SSL version in production.
    Therefore, it is quite important to understand your use case needs before implementing any workaround.
    Technical details on the browser attack are located here.

    A fix for the openssl packages that addresses the Fallback attack is available; the primary SSL3 exploit remains open. See "Fixing the Exploit" section below.

    Testing for the Vulnerability

    Three convenient tests exist to verify the status of concerned servers.
    1. Run this command on your server or remotely if easier to see if your server is vulnerable. This does not text specific applications on said server that may be configured to use SSLv3. Change the "$(hostname)" value to a FQDN.

    malchw@san-domino:~$if echo Q | openssl s_client -connect $(hostname):443 -ssl3 2> /dev/null | grep -v "Cipher.*0000"; then echo "SSLv3 enabled"; else echo "SSLv3 disabled"; fi


    Negative: SSLv3 disabled
    Positive: SSLv3 enabled

    2. Red Hat Access Lab created a SSLv3 (POODLE) Detector  GUI testing tool including a browser check, a BASH shell script to check servers offline, and a realtime check for public facing-servers via a FQDN and port of your choosing--launched from their network. You will need an RHN account to access it. I like the third option with Red Hat's tool because it can make easy work allowing customers while at work to check outside their office with ease.

    3. If you want a more verbose output, try the original test here
    malchw@san-domino:~$ openssl s_client -connect localhost:443 -ssl3

    malchw@san-domino:~$ openssl s_client -connect [hostname.foo.com]:443 -ssl3

    Note: Change the port number and hostname to suite your specific test case.

    Positive result

    If you see something similar to this, you are vulnerable
    Results - New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

    Server public key is 1024 bit

    Secure Renegotiation IS NOT supported

    Compression: NONE

    Expansion: NONE


    Protocol  : SSLv3

    Negative Result

    Else, you are fine, if this excerpt is close to your output:
    140128201074504:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40

    140128201074504:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:


    New, (NONE), Cipher is (NONE)

    Secure Renegotiation IS NOT supported

    Compression: NONE

    Expansion: NONESSL-Session:

    I suspect most servers with SSL will have SSL3 enabled, making the situation more wide-spread than some people may realize. This is operating system agnostic, so Microsoft, IBM, Red Hat, Oracle, VCE, et alia will all have upcoming product lists with affected products and tools, needing attention.

    Fixing The Exploit
    -- {Update 18 Oct 2014 - Patches released}
    Fix Announced
    -- 1 of {n}
    Red Hat offers a fix for POODLE's secondary Fallback attack exploit is available under advisory: RHSA-2014:1652-1 for RHEL 6, 7 plus address two memory leak fixes that can cause a crash; and RHSA-2014-1653-1 for RHEL 5.
    After patching, be certain to restart the httpd,ssld, and all other SSL-enabled services running on your box. And patch your box prior to applying this patch, to ensure success. Details from OpenSSL are available in their POODLE security advisory.

    "The openssl packages errata linked [above] do not address the SSL 3.0 protocol issue, to which the CVE-2014-3566 was assigned.  They add support for the TLS_FALLBACK_SCSV, which enables TLS servers to detect forced protocol downgrades against clients that do re-connect protocol version fallback.  Both server and client need to implement this feature, and clients have to actively use it for the protection to work." --Tomas Hoger, Red Hat Product Security

    If you need assistance in applying package updates from RHN, see article 11258.

    Further details on the main link provided as made available.

    {Update - four times this morning, plus early evening, 15 Oct, EDT}
    At this time a proper fix is unavailable. As of midnight EDT on Wednesday, Red Hat has not released a fix yet, but is working on it. Other companies will need to do the same, as well as browser ISVs to ensure compatibility. In the mean time, the suggested work-arounds are as follows:
    1. Disable SSLv3 on your servers
    2. Even if impractical to do disable SSLv3, consider using TLSv1.1 and TLSv1.2 with the  TLS_FALLBACK_SCSV parameter on your TLS servers enabled (Internet white paper draft available). This process may cause a few issues with some IBM products (to be fair, most vendors products will have issues even temporarily)
    3. If you run nginx, here is a solution: https://news.ycombinator.com/item?id=8456178
    4. If you are running Domino, you need a TLS 1.1+ server in-front of it, as IBM has not provided a solution; fellow IBM community member, Darren Duke has a work-around with Apache on Ubuntu utilizing TLS 1.2 (and v1.1) for advanced users
    --The problem with Domino as it is now is that if you remove SSLv2 and SSLv3, then you need a new TLS solution in-front of that server for protocols such as HTTP, SMTP, et alia.
    5. As Domino is directly impacted, please add your voice here as well

    {Update - 12:08 PM EDT}
    6. As Craig Wiseman reminded me, there are a few great (but hardly trivial) nginx workarounds published by the community
    Jesse Gallagher: Domino and SSL: Come with Me If You Want to Live
    Richard Moy: Installing Nginx Reverse Proxy on CentOS for Domino Our Experience
    Ray Davies: Domino Interface: Installing Nginx Reverse Proxy on CentOS for Domino Our Experience
    {End of Update}

    Red Hat's in-scope products (at this time) are here:
    Affected Component(s)
    Red Hat Enterprise Linux Tomcat, Firefox/Chromium, httpd, OpenSSL
    JBoss Enterprise Middleware Tomcat/JBoss Web, httpd, OpenSSL
    Red Hat Network Satellite Tomcat
    Red Hat Certificate System Tomcat
    Inktank Ceph Enterprise httpd
    Red Hat Enterprise OpenShift OpenShift Configuration , RHC client tools
    Red Hat Enterprise Linux OpenStack Platform httpd
    Red Hat CloudForms httpd
    Red Hat Directory Server Directory Server Configuration
    Red Hat Enterprise Virtualization RHEV-M


    1. Each affected component's hotspot offers a product specific technote on how to address the fix for the specific product and more focused testing too;
    2. The table is current at the time of this writing and may expand as a fix is released by Red Hat and other products identified
    3. To their credit Red Hat is working constantly to update their product list and resolution guides, adding the four appended rows to this table, early evening, 15 Oct 2014 EDT; and now a fifth for Enterprise Virtualization, late afternoon, 17 October 2014 EDT

    Google provided a white paper entitled, This POODLE Bites: Exploiting the SSL 3.0 Fallback, which provides greater detail on the TLS suggested settings and the exploit itself. Google is suggesting the use of TLS_FALLBACK_SCSV too.

    More later when a fix is released. Good luck.

    1Sean Cull  10/15/2014 3:59:25 AM  New SSL3 Exploit: The POODLE Is Here and Lifting Its Leg

    Bill, where a Domino server reports positive is there a way of disable SSL V3. The Internet Sites document says "SSL V3 is always enabled" next to the check box to disable V2 ?


    2Craig Wiseman  10/15/2014 6:32:30 AM  New SSL3 Exploit: The POODLE Is Here and Lifting Its Leg

    @Sean... here's where you ask yourself (and IBM), "Hmmm. What versions of SSL/TLS does Domino support? and the corollary, "Why has IBM not endeavored to keep Domino's security updated over the last FIVE YEARS?"

    Domino only supports up to SSL v3, it forces other TLS 1.0 server to downgrade to SSL v3 to communicate.

    (from wikipedia: TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security)

    { Link }

    *shakes fist at IBM*

    IBM hates its paying customers. And we remember this.

    3Bill Malchisky  10/15/2014 9:57:04 AM  New SSL3 Exploit: The POODLE Is Here and Lifting Its Leg

    Sean - I updated the blog post with an indirect response to your query. If you remove both SSL v2 and v3, then Domino would lack any TLS protection. So you would need to put in-front a solution for that. IHS was supposed to be that fix, but clearly is impractical for sites with multiple Domino boxes.

    Although uncertain when the initial PMR was created (suspecting in the V7 code stream), but the IdeaJam posts on it started in 2009. At the very least, a five year window which if implemented, would make today's exploit a non-event.

    Powered by IBM Lotus Domino 8 | Lotus User Group | Get Firefox! | This blog is listed on Planet Lotus   IBM Certified

    © 2010 William Malchisky.