CVE-2014-3566 POODLE vs. CVE-2014-8730 TLS POODLE
At F5 Networks we have seen a good deal of confusion over these two CVEs ever since they appeared late last year. As this is ongoing, we felt it needs to be addressed. The confusion is totally understandable; hopefully this will help.
There are two different, but related, vulnerabilities.
- CVE-2014-3566/POODLE is tied to SSLv3.
- CVE-2014-8730/TLS POODLE is tied to TLSv1.x
They are not the same thing. Much of the confusion stems from the latter being dubbed "TLS POODLE" after the original "POODLE" vulnerability was already well known. F5 Networks officially refers to it as the "TLS 1.x Padding Vulnerability", but that's a battle lost – many scan tools refer to it as TLS POODLE and we're stuck with the name and the resulting confusion.
F5 has two different SOLs for these CVEs:
If a scan indicates a vulnerability to 'POODLE', read it closely. If it mentions 'TLS' it is almost certainly referring to the latter CVE and not the former. F5's recommendation is to read both Solution Articles and to take appropriate measures to protect your systems from both CVEs.
Note that for CVE-2014-3566/POODLE there is no code fix and there will not be one. The only 'fix' is to disable SSLv3 as detailed in SOL15702. F5 disables SSLv3 in VIPs by default starting in 11.5.0; if it is re-enabled with a custom string it will re-enable the vulnerability, so be aware of that.
With CVE-2014-8730/TLS POODLE there is a code fix, and all of our latest releases have it, starting with 10.2.4 HF10, 11.2.1 HF13, 11.4.0 HF9, 11.4.1 HF6, 11.5.0 HF6, 11.5.1 HF6, and 11.6.0. Upgrading for the fix is the recommended solution, and F5 Networks always recommends upgrading to the latest Hotfix Rollup for a given branch.
NOTE: 11.3.0 is not in the list; it is EoSD (SOL5903) and will not be patched. 11.3.0 users are recommended to upgrade or to use the workaround in SOL15882.
For those who are unable upgrade at this time, there is a configuration workaround as detailed in SOL15882:
In 11.5.0+ use the cipher string !SSLv3:!ADH:AES-GCM:RC4-SHA
In 11.4.1 and earlier use the cipher string !SSLv3:RC4-SHA
This is where we often see a second level of confusion. Many have tried cipher strings such as "DEFAULT:!SSLv3:RC4-SHA" or "NATIVE:!SSLv3:RC4-SHA". These will not work; follow the SOL explicitly. Note that if you upgrade to a fixed version then you don't need to worry about the cipher string. (Other than ensuring SSLv3 is disabled for CVE-2014-3566, of course.)
The issue with the TLS Padding Vulnerability is with CBC mode ciphers. All of the ciphers supported by F5, aside from RC4 (and AES-GCM in 11.5.0+), are CBC mode. Note that not all CBC mode ciphers have 'CBC' in the name. This has caused confusion in many cases due to the belief that CBC is disabled because the string 'CBC' is not shown when listing the enabled ciphers. Yet scan tools still flag the system as vulnerable. If it isn't RC4 or AES-GCM, it is CBC mode and vulnerable on an unpatched system.
One last issue is specific to TMOS 10.2.4 HF10 & 11.2.1 HF13. While both of these are patched against CVE-2014-8730/TLS POODLE, some scan tools will return a false positive against them for this CVE. This is because, while they are patched, those versions are not sending a 'bad_record_mac alert' back to the client when it attempts to use incorrect padding. The tools aren't actually testing for the vulnerability, they're just looking for this alert; when they don't see the alert they falsely presume the system is vulnerable.
F5 Networks has ID500688: SSL does not send bad_record_mac alert when receiving the incorrect padding open for this issue. In the meantime we reassure you that the issue is fixed if you are running a patched version. If you wish to check, a packet capture should show the attempted connection with the bad padding being rejected, just not with the alert being sent back.
As always, if you have any questions or concerns, F5 Support is available to assist.
Additional reading:
CVE-2014-3566: Removing SSLv3 from BIG-IP
iRule to stop SSLv3 connections
POODLE and TLS_FALLBACK_SCSV deep dive
Published Feb 17, 2015
Version 1.0
- Great info...thanks for clarifying this important distinction!
Carl_Saiyed_158Nimbostratus
Thanks MegaZone for this well thought out article.
sandy16Altostratus
Hi Megazone, good stuff. Please make me understand the solution in SOL15882. We want fix this as upgrading might take us few months. Using the cipher !SSLv3:AES-GCM:RC4-SHA explicitily will disable/un-match the SSLv3:AES-GCM:RC4-SHA cipher because of the "!" regex. Don`t we need to disable/un-match all CBC related ciphers here? Moreover we are on 11.5.1 HF3, so sslv3 is already disabled.- MegaZone
SIRT
sandevsingh - You want to use '!SSLv3:AES-GCM:RC4-SHA' First, SSLv3 is only disabled *BY DEFAULT*. If you change the cipher string, it may no longer be disabled - and, in fact, in this case if you just used 'AES-GCM:RC4-SHA' you would re-enable it as RC4-SHA exists in SSLv3. So you'd end up enabling RC4-SHA for *all* protocols that have it, including SSLv3. Since you're replacing the cipher string you need to be careful about what gets re-enabled. You can check it with "tmm --clientciphers '!SSLv3:AES-GCM:RC4-SHA'" vs. "tmm --clientciphers 'AES-GCM:RC4-SHA'" As for the negation, it only applies to SSLv3. The '!' only applies to one term, not the whole string. !SSLv3:AES-GCM:RC4-SHA means HARD DISABLE SSLv3, ENABLE AES-GCM, and ENABLE RC4-SHA. So what you're left with are AES-GCM & RC4-SHA enabled for TLS. No other ciphers are enabled - so all CBC-mode ciphers are implicitly disabled. You're just enabling the non-CBC ciphers and leaving the rest out. 
BoyanBonev_2135test- BoyanBonev_2135I cannot post longer comments. Anyone aware of this?
- BoyanBonev_2135Hi, From what I understand from the article, the only allowed cipher suites which are not affected by the POODLE attack are RC4 ciphers. If this is the case then there might be an issue with this since Oracle has disabled the RC4 suites in their latest versions of the JVM (7u85 and 8u51). The motivation for this is because the RC4 suites are weak. I want to ask what is the recommendation for the case where java clients try to access the F5 through TLS and the only allowed ciphers are RC4 (because this is what's your recommended F5 config)?
- MegaZoneBoyanBonev - The recommendation is to upgrade your BIG-IP and then the whole thing is moot because the CVE was patched a long time ago. As it says in the article: "With CVE-2014-8730/TLS POODLE there is a code fix, and all of our latest releases have it, starting with 10.2.4 HF10, 11.2.1 HF13, 11.4.0 HF9, 11.4.1 HF6, 11.5.0 HF6, 11.5.1 HF6, and 11.6.0. Upgrading for the fix is the recommended solution, and F5 Networks always recommends upgrading to the latest Hotfix Rollup for a given branch." If you upgrade then you don't have to worry about which ciphers to use - the issue is fixed. If you don't upgrade, then you're stuck. You either have to use RC4 or accept the CVE vulnerability, period. And if the client won't support RC4 then either those clients are locked out - or you have to accept the CVE vulnerability. So, again, upgrade.
- BoyanBonev_2135Thanks! It seems upgrade is the only option.
Shiraz_84431For CVE-2014-3566, there is a fix in the latest versions:
