Bleichenbacher's CAT Puts Another Scratch in TLS

Bleichenbacher's CAT Puts Another Scratch in TLS
Are the underpinnings of HTTPS security as foolproof as everyone assumes they are?<br />The answer should be a resounding ‘yes’ unless, that is, you happen to be one of a small group of researchers who spend their time formulating what have come to be known as Bleichenbacher or Vaudenay padding oracle attacks.<br />There has been a steady trickle of these...

Are the underpinnings of HTTPS security as foolproof as everyone assumes they are?

The answer should be a resounding ‘yes’ unless, that is, you happen to be one of a small group of researchers who spend their time formulating what have come to be known as Bleichenbacher or Vaudenay padding oracle attacks.

There has been a steady trickle of these since an engineer called Daniel Bleichenbacher hypothesised the first and eponymous compromise of the RSA Public Key Cryptography Standard (PKCS) #1 v1.5 scheme in 1998.

The latest overlapping attacks made public last week (affected parties were informed in August) in the paper The 9 Lives of Bleichenbacher’s CAT: New Cache ATtacks on TLS Implementations, co-authors Eyal Ronen, Robert Gillham, Daniel Genkin, Adi Shamir (who co-invented RSA!), David Wong and Yuval Yarom.

Padding cats

The fundamental problem with the RSA key exchange protocols is that although only a few percent of servers still use them, SSL and even TLS (on which HTTPS depends) must remain backwards-compatible with them because that’s how internet security works.

This means that no matter how secure the later protocols are, attackers can keep scratching away at the theoretical weaknesses of the older parts of the system.

The new research tried a succession of compromises of the PKCS #1 element of the RSA protocols that defines how something secret (such as a symmetric AES 128-bit key) might be fitted into larger (say 2048-bit) RSA block key with the difference made up with what is called padding.

The padding oracle attack allows an attacker to infer this secret by bombarding the oracle (or server) with a random sequence of bytes and analysing the padding errors until no errors are returned.

Because previous mitigations countered this by limiting the number of queries that can be made with a given period, the researchers hit on a way to parallelise oracle attacks by sending queries to multiple servers secured by the same public key.

The researchers list other attacks, including cache-based side channel inference (FLUSH-RELOAD, PRIME-PROBE), before adapting older issues such as BEAST (Browser Exploit Against SSL/TLS), to see how easy it would be to target login tokens used by web browsers.

Importantly, the research once again showed that backwards compatibility and a slow upgrade cycle are the system’s Achilles’ heels. The security features of TLS 1.3 (which doesn’t support RSA key exchange) won’t help you if you can simply force a server to downgrade to an earlier version:

Supporting this small fraction of [RSA] users puts everyone at risk, as it allows the attacker to perform a downgrade attack by specifying RSA as the only public key algorithm supported by the server.

Of the nine RSA-based protocols tested by the team – OpenSSL, Amazon s2n, MbedTLS, Apple CoreTLS, Mozilla NSS, WolfSSL, GnuTLS, BearSSL and BoringSSL – only the latter two were able to resist the team’s new oracle padding Cache-like ATacks (CATs).

So, in summary, after 20 years of poking since Bleichenbacher, PKCS #1 keeps being broken, including secure protocols that were supposed to have mitigated its weaknesses.

Time to panic?

There are some caveats, the biggest of which is that the man-in-the-middle described in the research would need to have found a way to target the server from another virtual machine running on the same system, rather than remotely.

Getting to that privilege level would require some other compromise, including the ability to remain undetected within that environment. The compromises discussed in this research would not be trivial, probably enough to convince most experts not to be overly worried that a real attack exploiting them might come to pass.

So, it’s more a demonstration of the old adage that “attacks only ever get better” than a new, panic-inducing vulnerability.

However, just to be on the safe side the researchers recommend:

The safest counter-measure is to deprecate the RSA key exchange and switch to (Elliptic Curve) Diffie-Hellman key exchanges.

The problem is that getting rid of RSA once and for all will be a function of time rather than an edict from on high.

As long as support for RSA continues in the real world, Bleichenbacher is a name that will keep cropping up.

Source: nakedsecurity.sophos.com