Reading physical memory frame previously owned by another process to read contents of its memory page

Question

I had a conversation with @anger32 who states that zeroing a physical memory page frame when passing the page backed by that frame to another process is not the responsibility of OSes like Windows and Linux (though they do that, they don't guarantee that this will happen), but a responsibility of OSes with a certificate allowing it to work with classified information.

Is it possible to make the following attack on another (maybe more privileged) process?

1. map enough memory pages and start consuming enough CPU time to prevent zeroing thread, which has the lowest priority (at least on Windows), from getting CPU time.

2. another process places sensitive data into memory

3. context switch occurs

4. we ask the OS for a memory page, OS evicts that process' page and gives us the new page backed by the same page frame without zeroing it.

5. we scan the page for secrets.

He also states that there are ways to read another process' memory messing with mmap, its flags and physical addresses on Linux. Do you know any? Is it really possible to get another process' memory on Linux, for example memory of the process of another user or SELinux domain? If they are it looks like a very dangerous vulnerability.

Answer 1

I was curious of this myself once, and wrote a small program under linux that malloc'ed all available memory and dumped it to disk.

It turned out that it was all zeroed out before it was handed to my application.

Later, I also checked the kernel code, and could confirm it was the kernel who did it.

--

I think it makes perfectly sense that it is the OS responsibility to make sure old data is not made available to another process. Where else would you implement such a security measure?

Edit:

I do not remember if I tested against SWAP memory. Due to the disk IO required to zero out allocated disk space (memory), it might be implemented differently.

Answer 2

In Linux, processes is able to read another process memory when any of the following conditions applies:

1. The process had root permission or it can read /proc/$PID/mem or /dev/mem, by default /proc/$PID/mem and /dev/mem are only accessible by root
2. Parent process can fork()/clone() in such a way that allows it to read some or all memory of its child processes
3. A parent process can fork a child in such a way to allow the child process to read some or all the parent's memory
4. A process can set up shared memory area

A process can't read or write to the memory of an arbitrary, unrelated process unless the process runs with elevated privilege. In all other cases, you'd need to either be the parent process or the target process had to deliberately set up shared memory area.

That parent process can access a child process memory is the defining feature of most Unix systems. In Unix systems (including Linux), new process are created using fork() system call. fork() creates a copy of the existing process by creating a new entry in the OS process table, and sets up the new process virtual memory as copy on write of the parent's virtual memory. This does mean that the new process can read the parent's memory, but at this point, the new process is still executing the parent's code, so this is not a security issue. The new process may then call one of the exec*() system call to remap a new executable file into its own memory and jump to the start symbol of that executable file. The remapping means that now the only entry in the paging table on the new process virtual memory is the new executable. When the new process tries to read/write to the remapped area, it will cause a page fault and the OS will page the corresponding part of the executable file that was exec*()-ed into memory. If the new process tries to read/write to an unmapped memory area, this will cause a segmentation fault. In more advanced uses of fork and exec, a process can fork and then map the child process memory in such a way that all or parts of the child's memory will be accessible by the parent after exec*().

In Linux, when a process allocates memory (e.g. using malloc) from the OS, the process calls mmap() to allocate anonymous map. Anonymous map is served either from the RAM or swap. Anonymous mmap is zero filled by the kernel, unless the process requested MAP_UNINITIALIZED, which is only honoured on very constrained embedded systems for performance reasons, the kernel had to be compiled to allow this.

Additionally, for high security scenarios, Linux allows a process to request all or parts of its memory to be unswappable by using mlock and/or MAP_LOCKED. Locked memory is always served from RAM, and is usually used to prevent encryption keys and memory used for decryption to be swapped to persistent storage.

Answer 3

The attack you describe doesn't work on Windows. Starving the page-zeroing thread doesn't prevent zeroing, it only delays it. The existence of the page-zeroing background task is a performance optimization.

Basically, a naive memory manager with a privacy guarantee works like this:

• reserve a page from the freed list
• zero it
• make it available to application code (set page table entry to permit ring 3 access)

The optimized version looks more like:

• get a page from the zeroed list, if there is one
• if first step succeeded, skip to last step
• reserve a page from the freed list
• zero it
• make it available to application code (set page table entry to permit ring 3 access)

Starving the zeroing thread will result in slow allocation, because the zeroing hasn't been done yet. It won't result in data leakage, because the data structure keeps zeroed and leftover pages segregated, and when the allocator runs out of pre-zeroed pages, it has to do the zeroing just-in-time.

Answer 4

It is absolutely possible to read the memory of another process but this is only possible with administrative privileges and of course the OS won't allow any process to access any space of the memory that isn't assigned to that process.

For Administrative users this is of course possible. In Windows for example this functionality is implemented by default to debug a process. You can do this using the Task Manager like described here.

But its also possible to dump the whole memory including all processes and everything that is stored in memory at that time. This isn't that easy anymore because windows systems don't provide this functionality by default. To do this the application loads it's own memory drivers which allows them to access the memory directly and not through the OS.

On older linux systems we are able to dump the memory directly through the memory device in the /dev partition. This is not possible anymore but there are kernel modules that enable one to dump the whole memory too. This requires root privileges aswell. You can also do this manually for one process like described here.

//EDIT: I just asked a senior developer with 40 years of experience about this. The answer is: It relies on varoius factors. He told me in C++ and Java the variables are initialized which means that an application that is writen in C++ or Java wont be able to obtain the old information because it's overwritten by initializing that variable. But C does not do this so then it might be possible but then it still relies on the OS.

Answer 5

Technically, an operating system could recycle pages from processes that had the same security context, because any information the new process could gather from that would also be accessible to the process directly.

This is however completely impractical, because the security context of a process may change over time, and when privileges are dropped (which is a common pattern), the data contained in the process still needs to be protected from anyone with less access permissions than the original privilege set.

Given that privileges can also be fairly fine-grained, the effort to keep track of which processes a page may be given to without scrubbing it first is significantly higher than simply clearing every page returned to the operating system, especially as computer memory architecture heavily favours large sequential writes.

Some embedded architectures also use the DMA controller for this task, reducing the CPU time to a few cycles to set up the controller and acknowledge completion.

Whether a process may assume that freshly mapped pages are cleared is a contract between it and the operating system, but typically this is not assumed, and again there is usually little reason to do so, because processes still need to keep track of what data inside their address space they consider valid, and they would only do so for anything that really holds information.

If a task maps, modifies and unmaps pages rapidly, this will increase system load, and processes may become suspended while waiting for a low priority process to clear a page. Operating systems need to take care to not inadvertently introduce a priority inversion here, by temporarily increasing the priority of the zeroing task to that of the highest-priority task attempting to map a page.

Answer 6

Most OSes has to be certified to be used for certain purposes/in certain organisations. Most of them use the Common Criteria framework to different assurance levels and some levels require the OS to clear a page before handing it to another process. An indirect reference to this requirement, which states:

One reason zero-initialized pages are required is to meet various security requirements, such as the Common Criteria. Most Common Criteria profiles specify that user-mode processes must be given initialized page frames to prevent them from reading a previous process’s memory contents. Therefore, the memory manager gives user-mode processes zeroed page frames unless the page is being read in from a backing store. If that’s the case, the memory manager prefers to use nonzeroed page frames, initializing them with the data off the disk or remote storage.

(from Windows Internals, Part 2 6th ed. By Mark E. Russinovich, David A. Solomon, Alex Ionescu. Copyright © 2012 by David Solomon and Mark Russinovich)

Enabling such a feature most often requires the memory management architecture to be designed accordingly and it does not make sense to exclude this feature in a "civilian"/insecure version for non-obvious performance gains.

Specifically, it is important that kernel pages and pages from other users do not get leaked to unprivileged processes so they will have to cleared at some stage. It is also inefficient for a page to be zeroed unless it actually crosses above boundry (in case a page gets allocated back to the same process/kernel). So the only sensible time to do it is at the time of allocation and since the receiver cannot be trusted to do this, the OS will have to bear the responsibility. (Of course, real world OS will adopt all kinds of optimisations to reduce the delay of page allocation.)

Answer 7

The only working way to perform what are you talking about is a Cold Boot Attack, when you're destroying kernel by powering it off. OR you can try to play with kexec() calls, but it will not work in most of the cases.