4

pretty much the title, how to know if the Heartbleed vulnerability (for OpenSSL) affects other libraries like .NET's SSLStream or BouncyCastle.

(Sorry for ignorance, but have found no info on how to exploit, to see if is related to bufferoverruns and other things that shouldn't happen in Java/.NET).

closed as unclear what you're asking by Eric G, AviD Apr 10 '14 at 13:16

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I don't understand why you're asking about how a bug in specific library affect other libraries.... – AviD Apr 10 '14 at 13:17
  • because the bug is critical enough to stop production systems? – Fernando Gonzalez Sanchez Apr 10 '14 at 18:18
  • Update: I did some extra research & BouncyCastle does not provider server for TLS/SSL, just client, so not a problem (the problem is about deploying SSL server code with the vulnerability). And thanks for the answers, all have been useful. – Fernando Gonzalez Sanchez Apr 10 '14 at 18:22
  • The problem is not about SSL, it's about OpenSSL. A very specific package, that provides an implementation of SSL (among other things)... Nothing to do with any other SSL implementation. – AviD Apr 10 '14 at 20:40
  • That is very clear Sr., nobody discuses that. But the bug is so critical from security point of view that it was worth to check how well other libraries did about it. Just because it's another source code does not mean error cannot be committed again. – Fernando Gonzalez Sanchez Apr 11 '14 at 2:02
3

The so-called "heartbleed" exploit is a buffer overrun. A read overrun, to be specific: the attacked system is induced into reading and sending back bytes from a buffer which is much shorter than the read length, thus reading whatever bytes reside in RAM past the buffer. Since the bytes are sent back to the peer, this gives a window to peek into the target system RAM.

It is unlikely that any other implementation of SSL shares the same exact bug. It is plausible that other SSL libraries have buffer overruns of some sort (nobody really knows how to write bug-free code), but not exactly that one. Or, said otherwise, if another SSL implementation has the same heartbeat-related bug, then it probably is a spin-off of OpenSSL.

Moreover, for implementations written in a language where array accesses are systematically checked for bounds (typically Java or C# or Python or Scheme or OCaml or just about any language which is not awfully low-level like C), the consequences of a buffer overrun are different, and usually preferable: instead of reading the extra bytes and sending them back, the offending code traps, triggering an exception which implies termination of the thread or process or connection. The bug is still there, not the far-ranging exploit; the leakage of secret data has turned into a basic potential denial-of-service, which will often be limited to closing the affected connection, therefore not denying much service after all.

1

You can try run this from exploit-db. It will tell you whether the server's implementation return more than it should.

If you are not into seeing the inner working of the exploit you can try this or this

Not the answer you're looking for? Browse other questions tagged or ask your own question.