Modern OSes use virtual memory spaces for each process that leads to process isolation. So it is impossible for a webserver using the flawed OpenSSL library to read memory allocated to other processes (not explicitly shared with the process), at best attempts to do so would result in a segmentation fault.
The truth is heartbleed is a simple overread of a buffer by trusting the payload size being sent in an attacker controlled header and never verifying that the payload was actually that size and written to memory (see [1], [2], [3]). The attacker sends a heartbeat packet to the server with a header saying the length of its payload being sent (the size in the header is two bytes hence up to ff ff = 65535 bytes), writes the sent payload to memory, and then reads back data of that size back to the client which allows to read whatever is in memory in the webserver's process following the written payload. This is quite important as you can repeat the attack many times and eventually may get lucky and be able to get private keys for the HTTPS server, and at that point you can MitM the HTTPS server. (And get at things like erotic fan fiction or user's email). Yes, in the meantime you may come upon random data that the webserver was already serving up, but really the private keys (and less so session cookies) is the important part.
Furthermore, the scary part is that the attack does this in a way that will not be logged unless you are in a debug mode/eavesdropping every packet on the wire and log the beginning of every TLS handshake request.
This seems to imply that the heartbleed attack server compromises all of the computer's memory, not just that assigned to the webserver's processes and this is bad for reasons other than obtaining the private key at which point network eavesdropping and MitM attacks are possible. Is this true?
