According to http://heartbleed.com/, memory contents can be leaked from the server to the client and vice versa.
Say that I have been banking in a separate browser profile (but under the same user). If another browser profile happened to be targeted by the Heartbleed attack, does this mean that my banking session was possibly compromised? Does it matter whether Linux, Windows or something else is used?
There is a well-written analysis at http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html complete with code samples.
The author, Sean Cassidy, notes that (emphasis mine):
What if the requester didn't actually supply payload bytes, like she said she did? What if pl really is only one byte? Then the read from memcpy is going to read whatever memory was near the SSLv3 record.
And apparently, there's a lot of stuff nearby.
To be honest, I am a little surprised at the claims of the people who found the Heartbleed vulnerability. When I heard about it, I figured that 64KB wasn't enough to look for things like secret keys. The heap, on x86 at least, grows up, so I figured that pl would simply read into newly allocated memory, such as bp. Keys and the like would be allocated earlier, so you wouldn't be able to read them. Of course, with modern malloc implementations, this isn't always true.
And further, you won't be able to read the memory of any other process, so those "business critical documents" would need to be in memory of the process, less than 64KB, and be nearby pl.
An alternative viewpoint from Erik Cabetas of Include Security, commenting on Reddit:
Was having some discussions w/ my friend about this bug. He thinks it's exploitable by using a variety of specifically sized allocations across the heap to read the 64k chunks all around the heap fragments, not in a linear type of fashion that Sean in OP's link is implying. After thinking about the way ptmalloc/linux allocates, I think this is possible for sure. The .fi guys from codenomicron are sharp dudes, I bet they were able to get the allocations just right in a lab environment.
Edit: Sean has updated:
And apparently, there's a lot of stuff nearby.
There are two ways memory is dynamically allocated with malloc (at least on Linux): using sbrk and using mmap. If the memory is allocated with sbrk, then it uses the old heap-grows-up rules and limits what can be found with this, although multiple requests (especially simultaneously) could still find some fun stuff.
However, if mmap is used, all bets are off. Any memory not in use could be allocated for mmap. This is what the most of the attacks against Heartbleed will target.
And the best part: the bigger your requested block, the more likley it is to be served by mmap rather than sbrk.
To add on @scuzzy-delta's answer: by definition, buffer overruns in applicative code affect only applicative code. The operating system maintains the isolation between the various process, and won't permit a process to access the memory space of another process.
If the buffer overrun is of the "write" persuasion (the attacker forces the target to write bytes beyond the end of a buffer), then this may be turned into hostile hijack, in which the attacker takes control of the target application, and makes it do its bidding. Application-level privileges are already enough to enact considerable mischief, including reading (for instance) all of the browser's profile, grabbing the screen contents and keyboard entries, and so on (when it occurs on a "client" side, e.g. in a browser). However, in this case, the "heartbleed" vulnerability is a "read" overrun, revealing data but not impacting the target system. This precludes the immediate risk of hostile hijack and its dire consequences.
However...
Obtaining secrets from the applicative memory of the target process may be leveraged into a more extensive attack. For instance, if the target is a Web server, the heartbleed issue may reveal (with the appropriate amount of luck) the names and passwords of some other users, which can then be used to log on as these users. This can be problematic.
For a Web browser, i.e. on the client side, one may note that some browsers are on the habit of launching distinct process instances, to avoid memory fragmentation issues in long-running sessions, and also to avoid losing the whole browser when the Flash plugin crashes. Not all browsers do that, though -- and even for those who do, they don't do it systematically. They follow heuristics in order to group tabs "together" in a single process.
An extra point is that these process often use some shared memory to exchange some needed information, in particular password and cookie caches, and SSL sessions. Precisely the kind of juicy data that the attacker would like to obtain.
On the brighter side, attacking the client requires that the server that the client talks to runs the attack. It cannot be initiated by the attacker; it must wait for clients to connect.
