Canonical question regarding the recently disclosed padding oracle vulnerability in SSL v3. Other identical or significantly similar questions should be closed as a duplicate of this one.
product/browser]. Am I affected?product] vulnerable to the POODLE attack?product] with respect to this vulnerability?References:
The "Poodle" vulnerability, released on October 14th, 2014, is an attack on the SSL 3.0 protocol. It is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. Please note that we are talking about the old SSL 3.0, not TLS 1.0 or later. The TLS versions are not affected (neither is DTLS).
In a nutshell: when SSL 3.0 uses a block cipher in CBC mode, the encryption process for a record uses padding so that the data length is a multiple of the block size. For instance, suppose that 3DES is used, with 8-byte blocks. A MAC is computed over the record data (and the record sequence number, and some other header data) and appended to the data. Then 1 to 8 bytes are appended, so that the total length is a multiple of 8. Moreover, if n bytes are added at that step, then the last of these bytes must have value n-1. This is made so that decryption works.
Consider the decryption of a record: 3DES-CBC decryption is applied, then the very last byte is inspected: it should contain a value between 0 and 7, and that tells us how many other bytes were added for padding. These bytes are removed, and, crucially, their contents are ignored. This is the important point: there are bytes in the record that can be changed without the recipient minding in the slightest way.
The Poodle attack works in a chosen-plaintext context, like BEAST and CRIME before it. The attacker is interested in data that gets protected with SSL, and he can:
The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point, and injects some Javascript of their own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to a HTTPS site (say, a bank Web site) for which the victim's browser has a cookie. The attacker wants that cookie.
The attack proceeds byte-by-byte. The attacker's Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies a full-block padding. Suppose that the last 8 cookie bytes have values c0, c1, ... c7. Upon encryption, CBC works like this:
So if the previous encrypted block is e0, e1, ... e7, then what enters 3DES is c0 XOR e0, c1 XOR e1, ... c7 XOR e7. The ei values are known to the attacker (that's the encrypted result).
Then, the attacker, from the outside, replaces the last block of the encrypted record with a copy of the block that contains the last cookie byte. To understand what happens, you have to know how CBC decryption works:
The last ciphertext block thus gets decrypted, which yields a value ending with c7 XOR e7. That value is then XORed with the previous encrypted block. If the result ends with a byte of value 7 (that works with probability 1/256), then the padding removal step will remove the last 8 bytes, and end up with the intact cleartext and MAC, and the server will be content. Otherwise, either the last byte will not be in the 0..7 range, and the server will complain, or the last byte will be between 0 and 6, and the server will remove the wrong number of bytes, and the MAC will not match, and the server will complain. In other words, the attacker can observe the server's reaction to know whether the CBC decryption result found a 7, or something else. When a 7 is obtained, the last cookie byte is immediately revealed.
When the last cookie byte is obtained, the process is executed again with the previous byte, and so on.
The core point is that SSL 3.0 is defined as ignoring the padding bytes (except the last). These bytes are not covered by the MAC and don't have any defined value.
TLS 1.0 is not vulnerable because in TLS 1.0, the protocol specifies that all padding bytes must have the same value, and libraries implementing TLS verify that these bytes have the expected values. Thus, our attacker cannot get lucky with probability 1/256 (2-8), but with probability 1/18446744073709551616 (2-64), which is substantially worse.
[product]. Am I affected? Is [product] vulnerable to the Poodle attack ?The attack scenario requires the attacker to be able to inject data of their own, and to intercept the encrypted bytes. The only plausible context where such a thing happens is a Web browser, as explained above. In that case, Poodle is, like BEAST and CRIME, an attack on the client, not on the server.
If [product] is a Web browser, then you may be affected. But that also depends on the server. The protocol version used is a negotiation between client and server; SSL 3.0 will happen only if the server agrees. Thus, you might consider that your server is "vulnerable" if it allows SSL 3.0 to be used (this is technically incorrect, since the attack is client-side in a Web context, but I expect SSL-security-meters to work that way).
Conditions for the vulnerability to occur: SSL 3.0 supported, and selection of a CBC-based cipher suite (RC4 encryption has no padding, thus is not vulnerable to that specific attack -- but RC4 has other issues, of course).
Workarounds:
Any of these four solutions avoids the vulnerability.
[product] with respect to this vulnerability?Same as always. Your vendor publishes security fixes; install them. Install the patches. All the patches. Do that. For Poodle and for all other vulnerabilities. You cannot afford not to install them, and that is not new. You should already be doing that. If you do not install the patches then Níðhöggr will devour your spleen.
You don't ! Since the most probable attack setup involves the attacker luring the victim on their network, not yours.
Although, on the server side, you may want to react on an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.
Not to my knowledge. In fact, when you control all the external I/O of the victim, it is still considerably easier to simply lure the poor sod on a fake copy of their bank site. Cryptographic attacks are neat, but they involve more effort than exploiting the bottomless well of user's gullibility.
To disable SSL v3.0 support:
Either
Or
about:config into the navigation bar and press [Enter]tlssecurity.tls.version.min from 0 to 1 (0 = SSL 3.0; 1 = TLS 1.0)--ssl-version-min=tls1SSLProtocol All -SSLv2 -SSLv3sudo apache2ctl restart(%ZEUSHOME is the install location, usually /usr/local/zeus)
%ZEUSHOME%/web/global.cfg: tuning!ssl3_allow_rehandshake neversudo %ZEUSHOME%/restart-zeus"POODLE Attacks on SSLv3", ImperialViolet, ImperialViolet - POODLE attacks on SSLv3
"SSLv3 POODLE Vulnerability Official Release", InfoSec Handlers Diary Blog, > Internet Storm Center - Internet Security | SANS ISC
<ctrl>+<f12>, go to the tab Advanced, then on the left menu you click on Security. You will find a button saying Security protocols.... Click it, uncheck Enable SSL 3 and click OK. Now you are protected!
Commented
Oct 15, 2014 at 17:28
I've published a blog on how to disable SSLv3 in some of the most common bowsers and server platforms (https://scotthelme.co.uk/sslv3-goes-to-the-dogs-poodle-kills-off-protocol/). This should at least help answer the question on how to fully mitigate POODLE be you a client or a server.
Below are the key details.
The easiest and most robust solution to POODLE is to disable SSLv3 support on your server. This does bring with it a couple of caveats though. For web traffic, there are some legacy systems out there that won't be able to connect with anything other than SSLv3. For example, systems using IE6 and Windows XP installations without SP3, will no longer be able to communicate with any site that ditches SSLv3. According to figures released by CloudFlare, who have completely disabled SSLv3 across their entire customer estate, only a tiny fraction of their web traffic will be affected as 98.88% of Windows XP users connect with TLSv1.0 or better.
To disable SSLv3 on your Apache server you can configure it using the following, both in the SSL configuration section and in all SSL-enabled virtual hosts explicitly:
SSLProtocol All -SSLv2 -SSLv3
This will give you support for TLSv1.0, TLSv1.1 and TLSv1.2, but explicitly removes support for SSLv2 and SSLv3. Check the config and then restart Apache.
apachectl configtest
sudo service apache2 restart
Disabling SSLv3 support on NginX is also really easy.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Similar to the Apache config above, you will get TLSv1.0+ support and no SSL. You can check the config and restart.
sudo nginx -t
sudo service nginx restart
This one requires some registry tweaks and a server reboot but still isn't all that bad. Microsoft have a support article with the required information, but all you need to do is modify/create a registry DWORD value.
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders \SCHANNEL\Protocols
Inside protocols you will most likely have an SSL 2.0 key already, so create SSL 3.0 alongside it if needed. Under that create a Server key and inside there a DWORD value called Enabled with value 0. Once that's done reboot the server for the changes to take effect.
The easiest and probably the most widely used method to test anything to do with your SSL setup is the Qualys SSL Test. Simply navigate to the site, enter the domain for the website you want to test and hit submit to start the test.
Once the test has finished, you will get a nice summary of your results and a lot of detailed information further down the page. Specifically, you want to look in the Configuration section at your supported protocols.
What you want to see here is that you have no SSL protocols supported. You should have long since disabled SSLv2.0 and now we've just removed SSLv3.0 too. Supporting TLSv1.0 or better is good enough to support the absolute vast majority of internet users out there without exposing anyone to unecessary risk.
It is also possible to protect yourself from POODLE by disabling SSLv3 support in your browser. This means that even if the server does offer SSLv3 support, your browser will never use it, even during a protocol downgrade attack.
Firefox users can type about:config into their address bar and then security.tls.version.min into the search box. This will bring up the setting that needs to be changed from 0 to 1. The existing setting allows Firefox to use SSLv3 where it's available and if it's required. By changing the setting you will force Firefox to only ever use TLSv1.0 or better, which is not vulnerable to POODLE.
Chrome users don't have an option in the GUI to disable SSLv3 as Google removed it due to confusion over whether SSLv3 or TLSv1 was better with one having a higher numeric value. Instead you can add the command line flag --ssl-version-min=tls1 to enforce the use of TLS and prevent any connection using the SSL protocol. In Windows, right click on your Chrome shortcut, hit Properties and add the command line flag as seen in the image below.
If you use Google Chrome on Mac, Linux, Chrome OS or Android, you can follow these instructions here.
Fixing up Internet Explorer is also pretty easy. Go to Settings, Internet Options and click on the Advanced tab. Scroll down until you see the Use SSL 3.0 checkbox and uncheck it.
If you want to check that your browser changes have definitely removed SSLv3.0 support there are a couple of sites that you can use. If you visit https://zmap.io/sslv3/ with SSLv3 enabled in your browser, you will see the warning message I'm getting here in Chrome where I haven't yet disabled SSLv3. To double check the site was working as expected, I disabled SSLv3 support in Internet Explorer and opened up the site there too. Here you can see the difference.
You can also try https://www.poodletest.com/ alongside Zmap.
If you don't want to give away your site's name to these other websites, you can also test it with...
openssl s_client -ssl3 -host <your host name> -port 443
If it doesn't connect then you're ok.
But also make sure that your openssl is working properly with your site...
openssl s_client -host <your host name> -port 443
Disabling sslv3 also disables IE6 and Windows XP SP2 and below. Not many have IE6 but a lot still have Windows XP.
