Not out of the woods yet: There are more POODLEs

As I wrote in my previous article about this, in October a group of Google security researchers had discovered a problem, called POODLE, in SSL v3 that in combination with another issue, browsers’ automatic fallback to older TLS and SSL versions, allowed an attacker to quickly break the encryption of sensitive content, like cookies.

The main mitigating methods for this problem are disabling SSL v3 support, both server side (now down to 66.2%, but slowing down) and in the client, and to limit the automatic fallback, either by not falling back to SSL v3 (which is now implemented by several browsers), or by a new method called TLS_FALLBACK_SCSV (introduced by Google Chrome and others).

However, neither disabling SSL v3, nor implementing TLS_FALLBACK_SCSV will be enough to save us from every POODLE there is.

As part of my research for these articles, based on emails [1,2] from Brian Smith (formerly of Mozilla) to the TLS Working Group, I added a couple of more POODLE tests to the TLS Prober.

While TLS 1.1 and TLS 1.2 specifically require that the recipient must check that the bytes of the padding field match a specific value, TLS 1.0 only specified what the value should be, not that they should be checked. Brian’s emails mentioned that some years ago he had fixed a bug in NSS (the SSL/TLS implementation used in Netscape and, currently, Google Chrome) that enabled the POODLE attack against TLS 1.0 in versions of NSS prior to his fix. If one implementation could have had the problem, there were probably more that still have it.

The new test modified one of the padding bytes (used to make the encrypted block of data an even multiple of 8 or 16 bytes) that POODLE depends on the server not checking, and used them to test the implementations of the various TLS 1.x versions to discover if TLS 1.x servers were properly checking the padding bytes. There was no need to test SSL v3, as it is known to be vulnerable in all implementations.

Unfortunately, my scans indicate that 3.6% of servers do not check the padding for at least one TLS 1.x version when the protocol version of the connection is TLS 1.0 or higher. This means that, even if they have disabled SSL v3 (which 43% of the affected servers fortunately do), those servers are still vulnerable to a POODLE-style attack! This can happen because either the server only support that version, or the attacker can just force the client back to whichever TLS version is vulnerable, and even worse is that 4.24% of TLS 1.2 server have this problem even for TLS 1.2, which means no rollback attack is needed, at all, when attacking these servers.

Via Adam Langley of Google, I learned that they were aware of the issue and had informed vendors about the issue and were working on patches, scheduled for release yesterday.

A worrying part of what I found is that, while most of the affected servers were vulnerable for TLS 1.0, 3.3% of the affected servers were not vulnerable for TLS 1.0, but were for either TLS 1.1 and/or TLS 1.2. Considering that the format of the padding is the same in all three versions of TLS, by rights, if a server has the problem for one version, it should have them for the other versions it implements.

On the other hand, some implementors may have chosen to write separate implementations for each protocol implementation, to avoid breaking the other protocol version implementations when adding the new functionality. The downside of such an implementation philosophy is that one or more of the versions may have bugs that the others don’t have, and if you fix a bug in one implementation, it might still be present in the others because it didn’t get fixed in those implementations. It is quite possible that this is what originally happened in this case.

However, this area of TLS protocol has also been affected by other issues in the past couple of years, and it is possible that implementors chose to implement patches for those issues differently depending on the protocol version, due to other differences in the protocol, either because the implementations were already separate, or because the new code would be so complex it seemed better to do it that way.

My favorite candidate this to have happened is the patches for the Lucky Thirteen timing analysis attack that was discovered two years ago, and which required implementors to modify, in a very complex fashion, how all the client and servers check the padding and message integrity of TLS messages. This was needed to make sure it would take constant time to perform this operation, no matter whether the operation would succeed or fail, because the slightest timing difference could tell the attacker vital information about the transmitted data.

I think it is quite possible that some developers working on that patch, due to other differences in the protocol version formats, if their code wasn’t already organized that way, broke the rewrites out into separate code paths, and due to programming errors caused the padding check to behave differently in some of these paths, causing the  POODLE error to emerge in TLS 1.x implementations.

If correct, this might indicate that these implementations also have other bugs that could become vulnerabilities of similar severity as POODLE .

 

Mitigation

Unfortunately, mitigating this extended POODLE issue won’t be as simple as “disable SSL v3” was for getting rid of the first pack of POODLEs. All the affected servers must be updated.

This is an issue that cannot be mitigated by clients alone, as with the SSL v3 POODLE, since disabling any of the older TLS 1.x protocols is essentially out of the question. Clients can’t do that, since 61% of servers still only support TLS 1.0, and as mentioned, even servers with the newest version, TLS 1.2, are affected. The affected servers can’t disable TLS 1.x either, since in many cases their highest supported version is also vulnerable; they have to be upgraded to a version where the issue have been patched.

Looking ahead, there are encryption methods defined for TLS (for example,  AES-GCM, the AES Galois Counter Mode, ) that avoid the issues exploited by POODLE and other attacks, but both clients and servers have to be updated to support these methods, which are currently supported by 26% of the servers in my sample.

Additionally, there is also one method that updates the current TLS encryption format so that POODLE style attacks can be prevented. Earlier this year the IETF released a new extension of the TLS Protocol which changes how encryption and integrity checking is is done in TLS, called “Encrypt-then-MAC” (“MAC” is the “checksum” message integrity method used in TLS), as a response to numerous attacks on the current “MAC-then-encrypt” format. This new method includes the padding bytes in the integrity check, which was not done originally, meaning that an attacker cannot modify the padding in the fashion done by the POODLE attack. Unfortunately, at present, nobody has released this new feature in any clients or servers yet, in part due to problems with the definitions in the specification, and, like the Fallback SCSV, it requires that both clients and servers have to be updated, meaning that it will take a long time for full coverage.

Disabling SSL v3 will stop the SSL v3 POODLEs, but we are not out of the woods yet, as there are more POODLEs out there. Completely stopping them will require upgrading servers to fix the remaining padding issues, such as checking the padding, adding support of AES-GCM, implementing Encrypt-then-MAC, and to use TLS_FALLBACK_SCSV as a rollback protection mechanism.