I know this is very system dependent, but say we have a program, call it Program A. It contains sensitive data that a hacker wants to get into. One could simply close Program A, and run Program B that allocates lots of memory (malloc). Now since malloc doesn't usually clear the memory it allocates, you could potentially have access to Program A's memory.

Of course this would require lots of inspection of hex dumps and reverse engineering, but is this possible? Are there certain measures a program designer could take when designing an application to ensure this can't happen?

marked as duplicate by Alexander O'Mara, techraf, Gilles, sebastian nielsen, Stephane Aug 8 '16 at 6:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • With malloc you won't get memory that is currently in use by another process, unless there is a bug in the libc or the kernel.You may get memory that were by used by other processes before tho. – ott-- Aug 7 '16 at 20:56
  • @ott You wait until the program either closes, or frees that page of memory. Then you allocate memory to gain access to that page. – Chris Smith Aug 7 '16 at 20:58

For that hack to be reasonably possible, the hacker would need to already have full access to the program with sensitive information and your system, which means they'd also have direct access to the data used by the sensitive program. It also implies that no other memory is allocated or freed in between both instances or it would be otherwise impossible to plan how to access the proper memory segments.

The solution to protect yourself is therefore to protect your system at every single layer. This means to only install reliable software, have good antivirus protection (if appropriate), a good firewall, reliable administrators, and limit system access as much as reasonably possible.

If you wanted to prevent another program from being able to reallocate the same segments in a predictable fashion, you could use randomness in your memory allocations, but that would seriously increase the risk of implementing software bugs which would be harder to troubleshoot, while not making a practical difference because of the previously mentioned points.


Keep in mind that malloc uses the operating system's memory allocation functions to get large blocks of memory (e.g. VirtualAlloc, sbrk, mmap) and then hands out smaller blocks to callers of malloc. The OS functions that provide memory to a process will zero out the memory before giving the process access, so barring a bug in the OS, this isn't an issue.

  • While this does appear to be true now, it certainly wasn't the case in the past, so it is compiler and / or operating system dependent. – Julie Pelletier Aug 8 '16 at 4:24
  • When wasn't this true? Perhaps not true for DOS, but it's been this way for any semi-modern OS. – Swashbuckler Aug 9 '16 at 13:27
  • I haven't verified for such a situation for a decade but 10-12 years ago I can assure you it was true on most systems and definitely on SunOS. – Julie Pelletier Aug 9 '16 at 15:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.