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