The Heartbleed attack in OpenSSL 1.0.1 and beyond allows an attacker to get up to 64k of process data from a TLS heartbeat response. The 64k of data will quite often contain sensitive information such as keys or passwords. There are quite a few exploits in the wild already for this attack.
F5 has analyzed this attack and we are pleased to say that BIG-IP data traffic using an SSL profile with default ciphers is not vulnerable to this attack. BIG-IP SSL profiles terminate the SSL traffic on the BIG-IP, so the malicious heartbeat never gets to your webservers. TLS heartbeats are not enabled on current versions of BIG-IP, so any virtual server protected by an SSL profile is not vulnerable.
However, if you are not using the SSL termination capabilities of the BIG-IP, then the attack will pass directly through the BIG-IP and to the webservers. You may be vulnerable depending on the webservers you use.
BIG-IP versions 11.5.0 and 11.5.1 do use OpenSSL 1.0.1 for the management GUI and are vulnerable to the attack. Versions of BIG-IP older than 11.5 are not vulnerable.
F5 encourages using a private management network that is not connected to the internet.
A mitigation for virtual servers that do not use SSL termination
If you are using a simple load balancing virtual server without an SSL profile, then the traffic is passing directly to your webservers.
My great F5 colleagues and I have written an iRule that mitigates this vulnerability when the client sends a heartbeat. Since we haven't seen a valid client that sends heartbearts, we like this solution. If you have clients that do send valid heartbeats, then we have an iRule that watches for large heartbeat responses and kills the connection before they are sent to the client.
F5 LineRate Application Proxy product is not vulnerable by this bug as it uses openSSL version 0.9.8. Users could confirm this by entering bash shell and executing 'ssh -V' which will list openssl library version used by the system.
"However, if you are not using the SSL termination capabilities of the BIG-IP, then the attack will pass directly through the BIG-IP and to the webservers. You may be vulnerable depending on the webservers you use."
Are you talking about anyone that is not using the built-in ssl profiles at all (meaning they are not even using a VIP), or do you mean anyone that is using the ssl profiles but simply does not terminate it there and reencrypts the traffic to then send on to the destination server?
he is saying that if you are not offloading ssl, but simply load balancing ssl traffic back to servers that are offloading, then the vulnerability would need to be addressed at the servers themselves.
It should be noted that although Edge Client is linked to a vulnerable version of OpenSSL, it's nowhere near as risky as use of the same library on a server process which is actively listening all the time. In a client scenario, the listener must actively connect to a malicious server, and in the case of Edge Client, that possibility is remote (unless you're the type of person that blindly configures your VPN client to connect to just any 'ol server hostname that people send you).
The client components will be patched for sure; but don't slow down your mitigation tasks on your servers while hunting and fixing clients that use the vulnerable OpenSSL library...
