/proc/[pid]/mem write implications

/proc/[pid]/mem write implications

[Bryan Jacobs]

[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: /proc/[pid]/mem write implications

[Cong Wang]

On 01/29/2012 09:32 AM, Bryan Jacobs wrote:
> 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.

>
> 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.

Re: /proc/[pid]/mem write implications

[Alan Cox]

> > 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

Re: /proc/[pid]/mem write implications

[Indan Zupancic]

Hello,

On Sun, January 29, 2012 15:19, Alan Cox wrote:
>> > 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.

How did the patch enabling it get past review?

>
> 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.

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

Re: /proc/[pid]/mem write implications

[Alan Cox]

> 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