04-07-2014 07:23 PM
A new vulnerability has been discovered in OpenSSL that allows attackers to read arbitrary chunks of memory: heartbleed.com
Is Stingray Loadbalancer affected by this ?
Solved! Go to Solution.
04-07-2014 10:24 PM
You can check if your Stingray Traffic Manager HTTPS virtual services are vulnerable by going to Test your server for Heartbleed (CVE-2014-0160)
04-08-2014 02:28 AM
Actually this reply is not so helpful. The test site is overloaded and does not respond (currently), not to mention that we don't even know whether it is trustworthy and correct. Just because it is on Github and has a nice "official" heartbleed logo doesn't mean anything.
Given the severity of the issue, I would expect some sort of official statement regarding the products. In my case, I am running Stingray on my own hardware running on Debian Squeeze. Openssl is at 0.9.8*, so not vulnerable. But since I don't know the internals of Stingray, I would appreciate a more concise explanation whether or not services are vulnerable, and whether it depends on the Version of OpenSSL in the underlying OS.
04-08-2014 07:40 AM
I've done the test this morning and although the result is that we are not vulnerable, but I'm a bit confused, as to how.
We have hardware appliance (jetnexus), running TM version 9.4, on debian wheezy/sid, the version of openssl on the appliance is
# openssl version
OpenSSL 1.0.1 14 Mar 2012
# dpkg -l |grep openssl
ii openssl 1.0.1-4ubuntu5.10 Secure Socket Layer (SSL) binary and related cryptographic tools
Which I believe is vulnerable, so is the traffic manager doing something to prevent this? As I said, the tests seems to say its not vulnerable.
So my question is, how should we go about patching the openssl version on the appliance. I have opened a support ticket with our supplier but they haven't yet responded.
Any suggestion appreciated.
04-08-2014 02:31 PM
I've just been told the following.
Stingray Traffic Manager (software) is not vulnerable in any respect to this bug as we do not use OpenSSL for the SSL/TLS protocol (we have our own implementation).
Stingray Traffic Manager (virtual and hardware appliances): includes a vulnerable copy of the OpenSSL libssl library, but it is not linked into any process with open internet sockets - meaning that a default installation is technically affected by this bug, but is not vulnerable. Unsupported 3rd party software/scripts that start non-default services or use the library present on the VA may be vulnerable to the bug. Custom Health Monitors using commands that use openssl, e.g. wget, curl, or openssl s_client are vulnerable to a malicious MITM server.
You can also use this tool for offline testing as I don't trust the online checkers.
04-09-2014 12:40 AM
While the above all seems true, it would be good to see an official response from Riverbed rather than just a quote from an e-mail.
Additionally, is there any issue with removing the vulnerable OpenSSL library given it doesn't seem to be serving any purpose?
04-09-2014 01:56 AM
While the above all seems true, it would be good to see an official response from Riverbed rather than just a quote from an e-mail
Exactly! That's what I was after. Plus, maybe a little more technical information as to how the SSL implementation is better than OpenSSL. In our company, we are going to replace the ssl certs on every system that was potentially open to the exploit, so it makes a huge difference (regarding both budget and work) to know that the web sites behind our Zeus/STingray have not been vulnerable.
It seems as if we all need to contact the support individually to receive the desired official statement - at least that's what I will do.
04-09-2014 02:32 AM
I emailed their support and got a link to this page:https://supportkb.riverbed.com/support/index?page=
Next time I will remember to search their knowledgebase as well as their forum!
04-09-2014 03:03 AM
At the time when we started this discussion, searching for heartbleed or the CVE-ID did not turn up anything, but now we have what we are looking for. Thanks for providing the link ( and to Riverbed for providing the information ... )