3

I realize neither is foolproof, of course. I would just like to confirm my thought that it's harder for an attacker to get a memory dump than to copy from disk/flash-storage or that malware just tends to copy from disk more than it does from RAM. So that wherever possible, it's better to have the apps I write avoid getting sensitive material on disk, and better to keep it in memory until needed.

This is not about a specific scenario, it's the general rule that I'm interested in.

4

There's a lot of nuance. Each process should only be able to access the area of memory which is assigned to it by the kernel. With file/disk access each process may be able to read files owned by their calling user, files marked as readable for the calling user's group and world-readable files.

That said, in the case of virtual memory and suspend/hibernate actions there is the possibility that the sensitive data which an application is dealing with in memory is written to disk by the system. (EDIT: It's been pointed out that newly allocated process RAM will be zeroed by the kernel in most situations, so processes which are killed are not likely to leave much remanence in RAM. It is, however, possible for a process which freed a malloc'ed variable to have leftover data swimming around in it's address space if that same process later malloc's a new variable, but that's not as relevant here. The other points still apply) Lastly, if the process which is handling the sensitive data happens to have a buffer overread vulnerability then that would allow an attacker to provide that process with a crafted input which would allow that attacker to read the current memory space of the process. Including the sensitive data...

I'd recommend keeping any sensitive data encrypted until the time at which it is needed. Normally this means keeping it encrypted on disk and decrypting it at time of use, but it may also be feasible to keep it encrypted in memory and decrypt at time of use (assuming the decrypting keys are not also stored in memory).

  • As a follow-up, I'd look into recommended sensitive-data-handling procedures for each platform you're planning on developing for -- they vary between OS. Here's some notes for iOS: books.nowsecure.com/secure-mobile-development/en/… – mttat Jan 28 at 20:10
  • Even if it's encrypted, the app must have a way to decrypt it in order to use it, so that would be in memory/disk as well. – ispiro Jan 28 at 20:14
  • 3
    -1 This answer is incorrect. No modern operating system will give uninitialized memory from an old process to a new process. A new process' view of any memory allocated to it will always be that of a bunch of zeroed pages. Linux handles this by mapping the physical "zero page" to every page in the process' address space and triggering a page fault on write, and Windows handles this by running a kernel thread in the background that zeros memory after it has been released back to the kernel. – forest Jan 29 at 4:10
  • 1
    Fair point, I was thinking of malloc() and free() cycles within a same process. Editing my answer to reflect modern OS behavior for new memory allocations. – mttat Jan 29 at 23:06
  • 1
    It's better now. I changed my downvote to an upvote. – forest Jan 30 at 2:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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