Is Stingray Loadbalancer affected by OpenSSL heartbleed vulnerability ?

[rldx]

Hello,

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 ?

Thank you,

[steve_ollis]

You can check if your Stingray Traffic Manager HTTPS virtual services are vulnerable by going to Test your server for Heartbleed (CVE-2014-0160)

[rldx]

Thanks Stephen this helps me, this test didn't exist at the time I did my post

[ubabiak]

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.

Regards,

Ulrich

[akarim]

Hi Stephen,

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.

[kosch_1]

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.

https://github.com/FiloSottile/Heartbleed

[dhodges]

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?

[ubabiak]

dhodges schrieb:
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.

[jamiecon · Accepted solution]

All,

I emailed their support and got a link to this page:https://supportkb.riverbed.com/support/index?page=content&id=S23635 in about 5 seconds.

Next time I will remember to search their knowledgebase as well as their forum!

[ubabiak]

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 ... )