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