Shachar Shemesh wrote:
Hi all,
I have a question that touches on the security of a new tool I am
thinking of writing. In order to understand the threats, I need to know
the following. Supposing I have a process that does the following:
* Create a temporary file and open it read-only.
* Map that file into memory (using mmap in share mode) with a
read-only protection.
* Close the file descriptor
* Unlink the original file
After these operations, the process can change the memory content by
calling mprotect to turn the mapping into read-write, and then write
there. Assuming that particular avenue is blocked from it (i.e. - there
is an external program that monitors attempts to use mprotect over that
particular piece of memory and blocks it), what other avenues are
available to it?
In particular:
* Can it reopen the file somehow? I know it does not appear in
/proc/pid/fd (as there are no file descriptors pointing to it any
more)
* Can it get a second mapping of the file, somehow? In particular,
through /proc/pid/mem (obviously, the answer is "yes")? Can that
second mapping be turned into read-write? If so, will writing to
the second mapping affect the memory image appearing in the first
one?
* Is there another syscall, besides mprotect, that may change the
mapping to writable?
Are there any side effects to writing to this read only memory?
I mean suppose you memcpy the read area to a temporary buffer, unmap the
original file, mmap new memory into the same address space (using the
MAP_FIXED flag), then for anything running in the address space of that
application, it would look no different then changing the permissions of
the original.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: [EMAIL PROTECTED]
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
