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
