Roy Hernandez's picture

I may be a bit early on this but I have to ask about the POODLE exploit.  I am assumming that the fix will be in the install-security-updates?

Systems Affected

All systems and applications utilizing the Secure Socket Layer (SSL) 3.0 with cipher-block chaining (CBC) mode ciphers may be vulnerable. However, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack demonstrates this vulnerability using web browsers and web servers, which is one of the most likely exploitation scenarios.

Overview

US-CERT is aware of a design vulnerability found in the way SSL 3.0 handles block cipher mode padding. The POODLE attack demonstrates how an attacker can exploit this vulnerability to decrypt and extract information from inside an encrypted transaction.

Description

The SSL 3.0 vulnerability stems from the way blocks of data are encrypted under a specific type of encryption algorithm within the SSL protocol. The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then leverages this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate a large number of connections between the client and server.

While SSL 3.0 is an old encryption standard and has generally been replaced by Transport Layer Security (TLS) (which is not vulnerable in this way), most SSL/TLS implementations remain backwards compatible with SSL 3.0 to interoperate with legacy systems in the interest of a smooth user experience. Even if a client and server both support a version of TLS the SSL/TLS protocol suite allows for protocol version negotiation (being referred to as the “downgrade dance” in other reporting). The POODLE attack leverages the fact that when a secure connection attempt fails, servers will fall back to older protocols such as SSL 3.0. An attacker who can trigger a connection failure can then force the use of SSL 3.0 and attempt the new attack. [1]

Two other conditions must be met to successfully execute the POODLE attack: 1) the attacker must be able to control portions of the client side of the SSL connection (varying the length of the input) and 2) the attacker must have visibility of the resulting ciphertext. The most common way to achieve these conditions would be to act as Man-in-the-Middle (MITM), requiring a whole separate form of attack to establish that level of access.

These conditions make successful exploitation somewhat difficult. Environments that are already at above-average risk for MITM attacks (such as public WiFi) remove some of those challenges.

Impact

The POODLE attack can be used against any system or application that supports SSL 3.0 with CBC mode ciphers. This affects most current browsers and websites, but also includes any software that either references a vulnerable SSL/TLS library (e.g. OpenSSL) or implements the SSL/TLS protocol suite itself. By exploiting this vulnerability in a likely web-based scenario, an attacker can gain access to sensitive data passed within the encrypted web session, such as passwords, cookies and other authentication tokens that can then be used to gain more complete access to a website (impersonating that user, accessing database content, etc.).

Solution

There is currently no fix for the vulnerability SSL 3.0 itself, as the issue is fundamental to the protocol; however, disabling SSL 3.0 support in system/application configurations is the most viable solution currently available.

Some of the same researchers that discovered the vulnerability also developed a fix for one of the prerequisite conditions; TLS_FALLBACK_SCSV is a protocol extension that prevents MITM attackers from being able to force a protocol downgrade. OpenSSL has added support for TLS_FALLBACK_SCSV to their latest versions and recommend the following upgrades: [2]

  • OpenSSL 1.0.1 users should upgrade to 1.0.1j.
  • OpenSSL 1.0.0 users should upgrade to 1.0.0o.
  • OpenSSL 0.9.8 users should upgrade to 0.9.8zc.

Both clients and servers need to support TLS_FALLBACK_SCSV to prevent downgrade attacks.

Other SSL 3.0 implementations are most likely also affected by POODLE. Contact your vendor for details. Additional vendor information may be available in the National Vulnerability Database (NVD) entry for CVE-2014-3566. [3]

References

Revision History

  • October 17, 2014 Initial Release
Forum: 
Jeremy Davis's picture

When I saw the title I instantly thought it was just spam. But obviously it's not! Thanks for the heads up! I'll have a read and do some research and post back...! :)

Roy Hernandez's picture

Jeremy-

After posting it, I felt like the title was "too spammy" as well.  I just decided to keep the title and post the relavent details.  Thanks for looking into this exploit.

Jeremy Davis's picture

I just checked with the Debian security tracker (here specifically) and it has been patched in the wheezy-security repo. As such all TurnKey v13.x servers should be safe via auto security updates (at least from that vulnerability).

Please note that it has NOT yet been patched for squeeze-lts (i.e. TKL v12.x)! Any v12.x users would be well advised to either disable SSL (this looks pretty good but there would be plenty more available via google) or upgrade to v13.x (suggestions in this blog post).

Probably it's not a bad idea to disable SSL altogether regardless as it's probably only a matter of time before another vulnerability is discovered... In fact I just lodged an issue on the TKL tracker suggesting that it be the default config for v13.1 onwards.

Roy Hernandez's picture

Thanks for looking into this exploit.  You posted a lot of useful details regarding it's affects on TKL appliances.

Jeremy Davis's picture

And it seems that since I last checked, the OpenSSL version in Wheezy (security) has been downgraded back to 'vulnerable' again - and the Squeeze LTS version is still marked vulnerable! See CVE-2014-3566 on the Debian security tracker.

Apparently the fix provided was incomplete. So as of OpenSSL 1.0.1e-2+deb7u13 (Wheezy-security - i.e. TKL v13.x) and 0.9.8o-4squeeze17 (Squeeze LTS - i.e. TKL v12.x) the only way to make https on the server safe is to disable SSL! (so it relies on TLS instead).

Roy Hernandez's picture

yeah, this is definitely a nasty exploit.  I wonder why this one hasn't received the same hype as heartbleed and shell shock.  In fact, it seems worse than the shell shock exploit.

If it was downgraded, it makes me wonder if the fix was exploited out of development. ;)

Thanks for staying on top of this, Jeremy.

Roy Hernandez's picture

Looks like OpenSSL has fixed the issue in OpenSSL.

Vulnerability Note VU#577193

POODLE vulnerability in SSL 3.0

Original Release date: 17 Oct 2014 | Last revised: 27 Oct 2014

Overview

Many modern TLS clients can fall back to version 3.0 of the SSL protocol, which is vulnerable to a padding-oracle attack when Cypher-block chaining (CBC) mode is used. This is commonly referred to as the "POODLE" (Padding Oracle On Downgraded Legacy Encryption) attack.

Description

CWE-327: Use of a Broken or Risky Cryptographic Algorithm - CVE-2014-3566

Multiple implementations of SSL 3.0, including the implementation in OpenSSL up to version 1.0.1i, support the use of CBC mode. However, SSL 3.0 is vulnerable to a padding-oracle attack when CBC mode is used. A successful padding-oracle attack can provide an attacker with cleartext information from the encrypted communications.

Additionally, many modern TLS clients still support the ability to fall back to the SSL 3.0 protocol in order to communicate with legacy servers. A man-in-the-middle attacker may be able to force the protocol version negotiation sequence to downgrade to SSL 3.0, thereby opening up the opportunity to exploit the padding-oracle attack.

For more information, please refer to the original security advisory.

Impact

An adjacent, unauthenticated attacker may be able to derive cleartext information from communications that utilize the SSL 3.0 protocol with CBC mode.

Solution

OpenSSL has fixed the issue in OpenSSL versions 1.0.1j, 1.0.0o, and 0.9.8zc. For other implementations of the protocol, please check with the appropriate maintainer or vendor to determine if the implementation is affected by this issue. Additionally, consider the following workaround:

 

Use TLS_FALLBACK_SCSV

If disabling SSL 3.0 is not possible, TLS client and server implementations should make use of the TLS_FALLBACK_SCSV cipher suite value to prevent man-in-the-middle attackers from forcing unnecessary protocol downgrades.

Vendor Information (Learn More)

Vendor

Status

Date Notified

Date Updated

Apple Inc.

Affected

-

17 Oct 2014

Aruba Networks, Inc.

Affected

17 Oct 2014

20 Oct 2014

Attachmate

Affected

17 Oct 2014

27 Oct 2014

Mozilla

Affected

-

17 Oct 2014

Novell, Inc.

Affected

-

27 Oct 2014

OpenSSL

Affected

-

17 Oct 2014

SUSE Linux

Affected

-

27 Oct 2014

Legion of the Bouncy Castle

Not Affected

17 Oct 2014

20 Oct 2014

PeerSec Networks

Not Affected

17 Oct 2014

20 Oct 2014

Apache-SSL

Unknown

17 Oct 2014

17 Oct 2014

Apache HTTP Server Project

Unknown

17 Oct 2014

17 Oct 2014

Botan

Unknown

17 Oct 2014

17 Oct 2014

Certicom

Unknown

17 Oct 2014

17 Oct 2014

Cryptlib

Unknown

17 Oct 2014

17 Oct 2014

Crypto++ Library

Unknown

17 Oct 2014

17 Oct 2014

If you are a vendor and your product is affected, let us know.View More »

CVSS Metrics (Learn More)

Group

Score

Vector

Base

4.3

AV:N/AC:M/Au:N/C:P/I:N/A:N

Temporal

3.6

E:F/RL:OF/RC:C

Environmental

3.6

CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

Credit

This document was written by Todd Lewellen.

Other Information

  • CVE IDs: CVE-2014-3566
  • Date Public: 14 Oct 2014
  • Date First Published: 17 Oct 2014
  • Date Last Updated: 27 Oct 2014
  • Document Revision: 20

Feedback

If you have feedback, comments, or additional information about this vulnerability, please send us email.


View article...

 

Jeremy Davis's picture

This has prompted me to have another, closer look at the Debian Security Tracker - CVE-2014-3566. I see that OpenSSL in both Wheezy and Squeeze are still listed as vulnerable. Jessie and Sid have the new upstream versions and it appears that there have not been any patches backported (as they would normally do). TBH I'm not completely sure why this has not got more attention from the Debian Security Team. I also note that it's severity is only listed as 'medium'.

I hadn't noticed before but I also just saw; right at the bottom of the page (not particularly well highlighted) it states:

Fix is to disable SSLv3 in library or application configurations

That almost suggests to me that they expect end users to make that config change!? I don't think they would (or even would be able to) release a security update that would automatically do that for us... TBH I'm not sure where that leaves?!

Add new comment