/proc/[pid]/mem write implications
Dear LKML,
I have a few questions on the recent change to allow writing to /proc/[pid]/mem. If I understand correctly, the recent privilege-escalation vulnerability was fundamentally caused by incorrectly verifying that the memory being written to by a process was its own. The goal was to only allow processes to write to their own memory space - this was deemed harmless.
But I think that allowing arbitrary processes to write to **their own** memory via a file descriptor might in itself be problematic. Please, help me understand how this is safe.
Imagine an interpreted program running in a "secure" virtual machine. This machine makes certain guarantees about program behavior (typing, method privacy, &c) which it verifies through a combination of static analysis and runtime checks. These guarantees rely on the VM being able to instrument certain calls with the aforementioned runtime safety checks. The VM runs in the same address space as the interpreted program.
A concrete example of one such virtual machine is the Java VM. Another is the PHP interpreter.
Now, let's say this VM has a function for opening a file in the local filesystem. It outsources permissions checking to the host system; any file which the user launching the VM could read or write, the VM could also.
Let's say I run some interpreted code which opens up /proc/self/mem, seeks it to the VM's location in memory (possibly using a signature I know to orient myself in a randomized address space), I find the portion of the VM's code which handles the dynamic checking, and I brutally write NOPs all over it.
Now whenever the VM goes to make a safety check, it will pass, leaving any interpreted code hosted by that VM free to do whatever it likes!
I see that this could be countered by SELinux or other MAC schemes, but it seems to me like there may be a few ramifications to allowing arbitrary-address writes to one's own virtual address space which haven't been fully explored - or at least, I haven't seen any bulletins or significant discussion.
Please, let the more knowledgeable correct me. I want to be wrong very badly.
Bryan Jacobs
Quoted 8 lines · Bryan Jacobs
Dear LKML,
I have a few questions on the recent change to allow writing to /proc/[pid]/mem. If I understand correctly, the recent privilege-escalation vulnerability was fundamentally caused by incorrectly verifying that the memory being written to by a process was its own. The goal was to only allow processes to write to their own memory space - this was deemed harmless.
Well, the more fundamental vulnerability is the check was done in write(2) instead of open(2), which leaves a window for exploits.
Quoted 4 lines
But I think that allowing arbitrary processes to write to **their own** memory via a file descriptor might in itself be problematic. Please, help me understand how this is safe.
You will have a sysctl to control if it is writable.
Thanks.
Quoted 5 lines
Quoted 3 lines
But I think that allowing arbitrary processes to write to **their own** memory via a file descriptor might in itself be problematic. Please, help me understand how this is safe.
You will have a sysctl to control if it is writable.
The problem is not that the check is done in write, the problem is more fundamental - the open should bind to the memory of the executable image currently running, instead it effectively late binds each write to the image now being run. That is the root cause.
What's sad about this is that people went and re-introduced the bug and clearly didn't think to spend 2 minutes asking Google why the checks were there originally.
2006 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1359.html
2004 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1169.html
2002 thread
http://www.eros-os.org/pipermail/cap-talk/2002-May/000922.html
If you really want to fix this then you need to bind /proc/self/mem to the executable image in question, and you need to effectively revoke() that on exec so it can't be used to pin old images into memory.
Fix that and the rest falls out in the wash.
Alan
Hello,
Quoted 6 lines · Alan Cox
Quoted 5 lines
Quoted 3 lines
But I think that allowing arbitrary processes to write to **their own** memory via a file descriptor might in itself be problematic. Please, help me understand how this is safe.
You will have a sysctl to control if it is writable.
Quoted 8 lines
The problem is not that the check is done in write, the problem is more fundamental - the open should bind to the memory of the executable image currently running, instead it effectively late binds each write to the image now being run. That is the root cause.
What's sad about this is that people went and re-introduced the bug and clearly didn't think to spend 2 minutes asking Google why the checks were there originally.
How did the patch enabling it get past review?
Quoted 11 lines
2006 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0605.2/1359.html
2004 thread
http://lkml.indiana.edu/hypermail/linux/kernel/0407.0/1169.html
2002 thread
Quoted 8 lines
http://www.eros-os.org/pipermail/cap-talk/2002-May/000922.html
If you really want to fix this then you need to bind
/proc/self/memto the executable image in question, and you need to effectivelyrevoke()that on exec so it can't be used to pin old images into memory.Fix that and the rest falls out in the wash.
There is process_vm_writev() now, so there is no need for a writeable /proc/*/mem. User space can't count on it being writeable anyway.
Actually, as there is process_vm_readv() too now, I think /proc/*/mem should be removed altogether.
Greetings,
Indan
Quoted 4 lines
Now, let's say this VM has a function for opening a file in the local filesystem. It outsources permissions checking to the host system; any file which the user launching the VM could read or write, the VM could also.
If your vm allows opening arbitary special files you already lost.
Alan