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.


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

Impact
{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.
Note: 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

Results
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
SSL-Session:
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:

Product	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

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

• Comments [0]