Gilad Ben-Yossef wrote:
Are there any side effects to writing to this read only memory?
Terminology - with no limitation to the generality of what we are trying
to discuss here, let's call the program we don't trust "skype", and the
program that does the magic "jail". These are random hypothetical names,
and any relation to real programs is caused by excessive consumption of
mushrooms (AND without leaving me any, shame on you).
Jail is running skype while debugging it using the ptrace mechanism. It
is also the one that caused it to open the file in read only mode, mmap
it to memory and close the fd. The tricks are too horrendous to describe
here. Feel free to check out the head of "trunk" from SVN for
fakeroot-ng if you feel like going over the monstrosity of the code.
That particular piece of magic starts at the "allocate_process_memory"
function. Jail has the same memory mapped into its own address space
with read-write access.
Any time skype opens "/etc/passwd", we hold the syscall, translate the
path (relative or absolute, it doesn't matter) to an absolute path that
has a different root (say - /home/sun/skype/etc/passwd). Jail then
places that string into the shared memory (by writing into its own
read-write end of the shared memory, saving on the cumbersome and slow
ptrace interface for that - double gain), and changing the syscall
parameters to use the altered path. The memory has to be read only, or
skype could open two threads, open the file with one while changing the
memory with the other.
As you can see from that description, if the address which jail thinks
is used for the shared memory became read-write OR translated to
something other than the shared memory, the entire control jail has over
skype will be bypassed.
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.
I am still trying to figure out what the semantics are for munmap on
unallocated areas. I was thinking of simply failing the munmap and
returning EINVAL, but it seems that if you try to unmap an area that
contains unmapped areas (what I'm trying to emulate), munmap succeeds.
Either way, I have that scenario covered. I will not allow this area to
be unmapped.
What worries me is that skype may somehow manage to get another handle
on the original file and map it read-write somewhere else. This brings
the attack vector discussed above back at the table. That's why the file
is only mapped in two processes, both do not have any active fd pointing
to it, and the file no longer has a file system existence. The main
question is - is that enough to make sure no one else can access it?
Shachar
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
