My next class:

POODLE Strikes (Bites?) Again

Published: 2014-12-09. Last Updated: 2014-12-09 01:08:26 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

As Adam Langley notes in his blog [1], the POODLE vulnerability may be found in some implementations of TLS, not just in SSLv3.

The problem is an implementation issue, not so much a problem with the standard as in the original SSLv3 instance. The POODLE vulnerability was caused by SSLv3's use of unspecified, and unprotected use of padding. In TLS, the padding is specified, and TLS should no longer be vulnerable to the attack. However, it turns out that some implementations will not verify if the correct padding was used. An incorrect padding would go unnoticed (just like in SSLv3) and could lead to the POODLE problem.

On the other hand: We still haven't seen widespread (any?) exploitation of the POODLE vulnerability. So focus on what Microsoft has to offer first today, then take a look if you still have some outstanding "Poodles" in your network. F5 load-balancers apparently suffer from the new problem.

In addition, Heise.de notes that Kaspersky's Internet Security product, which implements a proxy on the protected host, still supports SSLv3 and may cause connections to be downgraded to SSLv3, even if the user's browser no longer supports SSLv3.

[1] https://www.imperialviolet.org 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords: poodle sslv3
3 comment(s)
My next class:

Comments

If you want to check your server: https://www.ssllabs.com/ssltest/
Any additional reference to this issue? is it being tracked on the original CVE?
Tracked on CVE-2014-8730

Diary Archives