Poodle SSLv3 vulnerability: What it is, how to discover it, how to defend against it

Google security researchers Bodo Moller, Thai Duong and Krzysztof Kotowicz recently uncovered a vulnerability in SSL 3.0 that could allow secure connections to be compromised by attackers.

The researchers are calling the attack POODLE, or Padding Oracle On Downgraded Legacy Encryption.

“SSL 3.0 is nearly 18 years old, but support for it remains widespread,” Moller wrote in a blog post describing the issue. “Most importantly, nearly all browsers support it and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions, including SSL 3.0.”

Fortunately a University of Michigan study shows that very few sites rely on SSL 3.0. Servers that support SSLv3 (along with other newer versions of TLS) are likely vulnerable to the attack. The report shows that this is 3 percent of the top 1 million domains on Alexa. Some still allow this technology since they wanted to allow users of old browsers to still access the site.

Johns Hopkins University cryptographer Matthew green said on his blog, “The problem with the obvious solution is that our aging Internet infrastructure is still loaded with crappy browsers and servers that can’t function without SSLv3 support.”

The type of attack available to hackers using this vulnerability is called man-in-the-middle and allows stealing of cookies which could allow an attacker to access sites with personal information.

Disabling SSL 3.0 support mitigates the problem but takes away legacy browser support.

The OpenSSL Project has released a new version of the encryption software, which patches several security flaws, including the bug that is exploited by the POODLE attack on SSLv3.

To address the issue, OpenSSL has added support for the TLS_FALLBACK_SCSV mechanism, which prevents attackers from being able to force downgrades from TLS to SSLv3.

“OpenSSL has added support for TLS_FALLBACK_SCSV to allow applications to block the ability for a MITM attacker to force a protocol downgrade,” the advisory says.

“Some client applications (such as browsers) will reconnect using a downgraded protocol to work around interoperability bugs in older servers. This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3.0 even if both sides of the connection support higher protocols. SSL 3.0 contains a number of weaknesses including POODLE (CVE-2014-3566).”

The updated versions of OpenSSL also include a fix for a high-risk vulnerability in the DTLS SRTP extension that can cause a memory leak.

“A flaw in the DTLS SRTP extension parsing code allows an attacker, who sends a carefully crafted handshake message, to cause OpenSSL to fail to free up to 64k of memory causing a memory leak. This could be exploited in a Denial Of Service attack. This issue affects OpenSSL 1.0.1 server implementations for both SSL/TLS and DTLS regardless of whether SRTP is used or configured. Implementations of OpenSSL that have been compiled with OPENSSL_NO_SRTP defined are not affected,” the advisory says.

There also is a patch for a low-risk vulnerability that results from a problem in the “no-ssl3″ build option that could still allow servers to complete an SSLv3 handshake.

The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it.

If either side supports only SSL 3.0, then all hope is gone, and a serious update required to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability.

Disabling SSL 3.0 entirely right away may not be practical if it is needed occasionally to work with legacy systems. Also, similar protocol version downgrades are still a concern with newer protocol versions (although not nearly as severe as with SSL 3.0). The

TLS_FALLBACK_SCSV mechanism from [draft­ietf­tls­downgrade­scsv­00] addresses the broader issue across protocol versions versions, and we consider it crucial especially for systems that maintain SSL 3.0 compatibility. The following recommendations summarize how TLS_FALLBACK_SCSV works.

TLS clients that use a downgrade dance to improve interoperability should include the value 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites in any fallback handshakes. This value serves as a signal allowing updated servers to reject the connection in case of a downgrade attack. Clients should always fall back to the next lower version (if starting at TLS 1.2, try TLS 1.1 next, then TLS 1.0, then SSL 3.0) because skipping a protocol version forgoes its better security. (With TLS_FALLBACK_SCSV, skipping a version also could entirely prevent a successful handshake if it happens to be the version that should be used with the server in question.)

In TLS servers, whenever an incoming connection includes 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites, compare ClientHello.client_version to the highest protocol version supported by the server. If the server supports a version higher than the one indicated by the client, reject the connection with a fatal alert (preferably, inappropriate_fallback(86) from [draft­ietf­tls­downgrade­scsv­00]).

This use of TLS_FALLBACK_SCSV will ensure that SSL 3.0 is used only when a legacy implementation is involved: attackers can no longer force a protocol downgrade. (Attacks remain possible if both parties allow SSL 3.0 but one of them is not updated to support TLS_FALLBACK_SCSV, provided that the client implements a downgrade dance down to SSL 3.0.).

In Unified VRM, you can detect the Poodle SSLv3 vulnerability by either checking for the OpenSSL library version with various vulnerability checks, or you can check for weak SSL ciphers and then disable SSLv3 if it practical.

Please contact our support if you need assistance on this.