June 2014 OpenSSL Vulnerabilities
On June 5th 2014, the OpenSSL project released some new vulnerabilities on the tail of the heartbleed vulnerability.
F5 fared pretty well through heartbleed because TLS terminating virtual servers were not affected and we even had the ability to stop heartbleed attacks against simple TCP virtual servers.
The latest OpenSSL vulnerabilities are not quite as bad. This article will go into depth on 2 of the vulnerabilities and explain the others.
Let’s start with the easy ones and progress up to the fun ones.
CVE-2014-3470 Anonymous ECDH DoS attack
If a server advertises anonymous elliptic curve Diffie-Hellman ciphers, a malicious client could crash the server. F5 BIG-IP does not support anonymous ECDH ciphers on the management interface nor for dataplane traffic so we are not vulnerable. We have created ID465805 to track this vulnerability.
CVE-2014-0198 and CVE-2010-5298 SSL_MODE_RELEASE_BUFFERS
SSL_MODE_RELEASE_BUFFERS is a special flag that will treat OpenSSL memory slightly differently. F5 does not use this flag and are not vulnerable to this issue. We have created ID465804 for tracking purposes.
DTLS flaws
This is where it gets fun. DTLS is rather new, but is essentially TLS over UDP instead of TCP.
CVE-2014-0221 DTLS handshake flaw
This flaw happens when a server sends a malicious handshake message to a client. BIG-IP does not by default contain any DTLS clients and is not vulnerable. If you are using BIG-IP as a DTLS client, F5 will be patching all older releases over time. ID465803 has been created.
CVE-2014-0195 DTLS fragmentation issue
This is more worrisome, but BIG-IPs are still not vulnerable.
OpenSSL has a flaw that could allow remote code execution from a DTLS message fragmented across UDP messages.
It’s easiest to illustrate the vulnerability.
Here is a simple example of a 300 byte message spread across 3 DTLS fragments.
100 bytes are sent every message until we have a complete message.
The flaw happens when OpenSSL allocates memory for the initial message.
First, let’s start with the same initial fragmented message.
OpenSSL allocates space for 300 bytes. You know where this is going, right?
Next the attacker sends another fragment.
This time, the attacker sends a fragment with a new 1000 byte length and 900 bytes of data. OpenSSL tries to write 900 bytes into the 200 bytes that are left in the buffer and bad things happen.
F5 BIG-IP does not support DTLS for the management traffic, so BIG-IP is not vulnerable.
This flaw does not exist in the dataplane NATIVE DTLS code so BIG-IP is not vulnerable. If you are using COMPAT ciphers (not the default on later versions of BIG-IP) then you may be vulnerable..
CVE-2014-0224 Change Cipher Spec message
This is a great vulnerability. It’s got a lot of complicated elements and it’s not intuitive.
We have to first start with a man in the middle of our infant TLS connection. The attack happens before the server certificate has been checked and the attacker never tries to impersonate the server so the users’ browser will not even pop up a warning for a bad certificate.
The MITM watches as the client sends his CLIENT_HELLO message. He passes that unmodified to the server.
At this point, the MITM sends a Change Cipher Spec message to both the client and the server. This is a simple message that tells the server and the client that all new messages should use a new cipher. This message usually happens after a renegotiation
Sending a CCS message during the handshake is forbidden by the protocol, but OpenSSL has ignored it since OpenSSL 0.9.8.
New code was introduced into OpenSSL 1.0.1 to lock the TLS pre-master secret when a CCS message is received. This pre-master secret is used to generate the session key. It should be decided randomly later in the handshake.
Since the pre-master secret is now set at a predictable value, the MITM can guess the session key. He can continue passing all further messages between the client and the server, but since he has the session key, all traffic can be decrypted or even modified.
OpenSSL fixed the problem in OpenSSL 1.0.1h by dropping the connection when an early CCS message is received.
The only way to be vulnerable to CVE-2014-0224 is to have an OpenSSL 1.0.1 server and an OpenSSL 0.9.8 or higher client.
BIG-IP 11.5.0 and 11.5.1 use OpenSSL 1.0.1 for the management interface, so we are vulnerable. We are tracking this with ID 465799 and will be releasing a patch shortly. For now, you should ensure your management interface is isolated to a private network. We will be releasing fixes for all supported BIG-IP versions over time to patch the vulnerable clients that may be on the BIG-IP.
See SOL 15325 for more information.
However, there is good news. Dataplane virtual severs configured to use TLS termination are not vulnerable to this attack (unless you are using COMPAT ciphers; not the default). BIG-IP queues the CCS message and does not set the pre-master secret like OpenSSL.
If you are using straight TCP virtual servers, then the attack will be passed through directly to your SSL servers. You could use a variant of the heartbleed mitigation iRule to stop early CCS messages. My team hasn’t written this iRule yet; it only needs to watch for a CCS message before the initial handshake is completed. If it occurs, the connection should be dropped. This is how patched OpenSSL operates.
I must point out there are some tools in existence that incorrectly claim that BIG-IP TLS virtual servers are vulnerable. The tools merely send a client HELLO message and then immediately send a CCS message. If the server does not shut down the connection, then the tool claims the server is vulnerable.
Even though we are not vulnerable, F5 plans to change our behavior to match OpenSSL. This is currently being tracked as ID465908 and will be released in hotfixes over time.
Conclusion
The OpenSSL saga keeps going. Heartbleed has put a lot of scrutiny on the code.
F5 will continue to watch for vulnerable code and patch as needed.
I hope you enjoyed this deep dive into the latest OpenSSL vulnerabilities.
