If I have a web crawler (using a non-patched version of OpenSSL) that can be coaxed to connect to an evil https-site, can they get everything from my process memory? To attack a server you can keep reconnecting to get more 64kb blocks (if I understand correctly), but can a client be forced to reconnect many times, to get more blocks?

@MattNordhoff yeah. After all the purpose of the Heartbeat extension is to keep the SSL/TLS session alive. So you steal memory from the client AND keep the sessio alive to steal more. Just perfect.
–
DakatineApr 16 '14 at 17:46

I don't get the client side risk. What happens if: - a client has a non affected OpenSSL version and connects to - a server with an affected OpenSSL? Can be the client compromised in this case?
–
TeddySep 18 '14 at 8:03

Note that some of these programs do not use OpenSSL. For example, curl can be built with Mozilla NSS and Exim can be built with GnuTLS (as is done on Debian).

Other common clients:

Windows (all versions): Probably unaffected (uses SChannel/SSPI), but attention should be paid to the TLS implementations in individual applications. For example, Cygwin users should update their OpenSSL packages.

OSX and iOS (all versions): Probably unaffected. SANS implies it may be vulnerable by saying "OS X Mavericks has NO PATCH available", butothersnote that OSX 10.9 ships with OpenSSL 0.9.8y, which is not affected. Apple says: "OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS"

For my specific needs, I am not so concerned about someone decrypting my connection. I want to know if, as reported by some sources, this vulnerability can be used to read everything in the client process' memory.
–
GurgehApr 8 '14 at 15:13

@scuzzy-delta I made Pacemaker in an attempt to show that clients are definitely affected. The current implementation does not require valid certificates and can leak some data depending on the client. Perhaps more interesting memory can be leaked when the handshake is complete, but that requires more work.
–
LekensteynApr 9 '14 at 11:23

Furthermore you might have client side software on your computer that
could expose the data from your computer if you connect to compromised
services.

Of course, and this is not just the case for this vulnerability or for a particular client, the client still has to initiate the connection to be attacked. In no way this vulnerability allows an attacker to initiate a connection to your web crawler and exploit the vulnerability.

In your case however, as you have a direct control over the OpenSSL client code (and I suppose this is the case based on your post), you want to ensure that your version of OpenSSL doesn't come with the Heartbeat option, and if it does, to remove it. In order to do so, you can:

display which specific options were used to compile your version of
OpenSSL :

openssl version -o

or display every information from your OpenSSL version :

openssl version -a

compile OpenSSL without Heartbeat support, by simply using this flag at compile time :

-DOPENSSL_NO_HEARTBEATS

Once this is done, or if your version of OpenSSL didn't include it initially, then you are not vulnerable.

Edit: Another method is to retrieve your OpenSSL version with:

openssl version

And compare it to the list of affected versions available on heartbleed :

Do you have sources to back this up? heartbleed.com claims that both directions are affected.
–
LekensteynApr 8 '14 at 13:31

My answer was definitely vague, I edited it. The key message was: "no, you are not at risk given that you have direct control over the OpenSSL client and can change your settings", as opposed to the majority of affected servers & clients that cannot be changed so easily.
–
ack__Apr 8 '14 at 14:08

Also, sources have been given by @scuzzy-delta already. The main source of information about this bug is http://heartbleed.com, and many other websites are spreading it now.
–
ack__Apr 8 '14 at 14:25

1

please bear in mind that at least redhat's fix is backported to 'e', so its no longer quite true that f(inclusive) is vulnerable
–
SirexApr 9 '14 at 3:13

1

@Sirex There was a post on one of the other SE sites, Ubuntu apparently backported it all the way to 1.0.1, so yeah, people should check their distro's news list or other info for what is safe.
–
TC1Apr 9 '14 at 9:33