Following a flood of requests from our customers about the recently discovered Heartbleed bug in OpenSSL, we decided to go ahead and publish an official statement about the problem and its relation to our (and therefore your) security products. We tried to do our best to make the explanation as simple and straightforward as possible. This statement primarily targets the users of SecureBlackbox and BizCrypto software, as they use SSL/TLS functionality provided by these products.
Q. Are EldoS products subject to the Heartbleed bug?
A. No they aren't. It's a mistake in OpenSSL code that makes the Heartbleed attack possible. As neither SecureBlackbox nor any other EldoS product use OpenSSL, they are not exploitable.
Q. Is there anything I can/should do to reduce the risk?
A. Unfortunately, there is nothing you can do with SecureBlackbox to reduce the risk. Heartbleed is not an exploitable bug of a particular SSL/TLS session; instead, it is a method which allows to use rogue SSL/TLS sessions for stealing information about legal SSL/TLS sessions. So the primary goal for now should be patching vulnerable OpenSSL installations (1.0.1 through 1.0.1f (inclusive)) as quickly as possible.
Q. Will there be a patch in SecureBlackbox?
A. There is no need in a patch (nor there technically can be). The only way to address the vulnerability is to patch the affected OpenSSL installations (1.0.1 through 1.0.1f inclusive).
Q. Can you tell me more about the bug?
A. SSL/TLS gets use of so-called keep-alive requests that might be used to prevent idling sessions from closing by timeout. Basically, a party (e.g. a client) sends a chunk of arbitrary data prepended with a two-byte length indicator (e.g. 0x00, 0x09, 'h', 'e', 'y', ' ', 't', 'h', 'e', 'r', 'e') to the other party (i.e. the server). The server echoes the data back, letting the client and all the routing components in the middle know the connection is still alive. However, a rogue client might send something like this: 0xFF, 0xFF, 'h', 'e', 'y', ' ', 't', 'h', 'e', 'r', 'e' (i.e. specify that the length of the arbitrary data is 65535, while only send 9 bytes of the payload). A vulnerable server won't check the bounds and will reply with 65535 bytes of data, first nine of which are 'hey there' and the remaining 65526 are anything residing in the server's memory beyond the initial data. This can be anything, including data belonging to a different SSL session on the same server. As the attack is really easy to carry out, and as there is no way to identify it on the server, the scale of the vulnerability is really wide.
You will find more details about the vulnerability at the following
http://heartbleed.com/ http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html http://www.reddit.com/r/technology/comments/22h163/critical_crypto_bug_in_openssl_opens_twothirds_of/ http://www.reddit.com/r/programming/comments/22ghj1/the_heartbleed_bug/