linux-kernel - /proc/[pid]/mem write implications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120128203250.090abec6@easytoremember.us>
Date:	Sat, 28 Jan 2012 20:32:50 -0500
From:	Bryan Jacobs <its@...ytoremember.us>
To:	linux-kernel@...r.kernel.org
Subject: /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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)