Heartbleed issues in virtual environments

I've had a lot of customers email in asking about openSSL heartbleed related concerns after the announcement last week. There is an informational website setup here to explain the issue in detail.

First thing I want to say here is that this is information that  I've been able to track down, but in no way is this a complete list of everything effected. It is merely a list of items I currently work with that happen to be a part of a lot of my customers solutions. This issue is widespread and evolving quickly so there will obviously be changes to what is listed in this article.

OpenSSL released a security advisory on this issue;

"OpenSSL Security Advisory [07 Apr 2014]
========================================

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.0.2 will be fixed in 1.0.2-beta2."

Basically this issue allows somebody to grab 64k chunks of data out of memory on a server utilizing OpenSSL. As a result this data could be used to figure out the private key associated with certificates used to secure content. The result of this would be the private key being used to de-crypt a datastream and view what is supposed to be a secure encrypted transmission between two endpoints. Most of the manufacturers are scrambling to figure out a solution to this issue. I will provide some info and useful links to the Vendors we commonly work with to supply our customers with top of the line solutions.

VMware

VMware has released information on this issue including which products are affected by the security vulnerability. This official VMware blog post has some info, however you'll want to view this KB article to see the products and info affected.

Products Affected include

EMC

EMC has posted an advisory here you'll need powerlink/support credentials to get in to view the advisory. The vast majority of the products are NOT affected. The list of effected products is

Cisco

Cisco has also released a statement on this issue as well. They have a preliminary list of devices that are affected, seen below, but follow the link in above to get to the statement. The list will likely changed, they have gone through the entire portfolio yet. Most notably the Cisco UCS platform seems to be in the clear.

Hewlett-Packard

HP also released a statement, not with much detail, however they have ruled out some of the product line. The statement can be found here.

Teradici

Anyone using VMware View and Zero Clients should note that the PCoIP Management Consoles from version 1.9.0 to 1.10.0 are effected. An upgrade will fix this. More info here

Microsoft

Last, but not least this time is Microsoft. Not surprisingly Microsoft products seem to be uneffected because they don't use openssl typically for anything. IIS, among other secured products in their portfolio, do not use OpenSSL and is therefore uneffected.


In closing, I would recommend following the advice of the manufacturer in resolving the issue. Also if you have management devices that are affected that are on a private VLAN don't worry as much about them because you have physical control over who's accessing them. Start with your most public facing devices and work your way back into the network.