Re: handle protection - please comment

[Corinna Vinschen <vinschen at redhat dot com>]

On Wed, Apr 18, 2001 at 02:47:00PM +0400, egor duda wrote:
> Hi!
> 
> Wednesday, 18 April, 2001 Robert Collins robert.collins@itdomain.com.au wrote:
> 
> RC> The thing egor as talking about was child process's needing to read the
> RC> parents open handles, and that programs than setuid are apparently
> RC> setting the perms to everyone, all to allow the child process with it's
> RC> different uid to read the handles. He was proposing a server model,
> RC> which I don't like because
> RC> a) it adds complexity and overhead
> RC> b) I don't believe _we_ should be doing the access checking, we should
> RC> be passing that back to NT to do.
> 
> i can't see how you can avoid server model. Here's my rationale:
> 
> 1. process A which opens tty (not necessary child, it can be any
> unrelated process, which opens, say, /dev/tty0) have to obtain handle
> of tty pipes.
> 2. Only way to obtain this pipe handles under win32 is to call
> DuplicateHandle() from address space of process B, which is master for
> tty0
> 3. To call DuplicateHandle () we must have handle of process B. Having
> this handle we can ReadProcessMamory() and WriteProcessMemory() to the
> address space of process A.
> 4. Even if we restrict hProcessB to allow only handle duplication, but
> denying READ_VM and WRITE_VM, it wont help much. Malicious attacker
> can run this code:
>   for (void* h = 0; ; h += 4)
>     {
>       h1 = duplicate_handle_from_process_b (h);
>       if (ReadProcessMemory (h1, 0x61000000, buffer, 4096, &bytes_transfeered))
>         {
>           printf ("Hooray! Got it at %p", h);
>           do_bad_things ();
>           break;
>         }
>     }
> to scan process' B handles in hope to find hMainProcess handle. And i
> bet it won't take long to find it.

Maybe I'm somewhat slow but isn't the situation exactly the other way
around?

Process A needs a handle to a thing T which is owned by process B.
To get the handle, the owner B needs to get the process handle of
A to duplicate the handle and return it to A. So if A is the attacker
it has no chance to undergo the permissions of B since it never
sees the process handle of B. OTOH, if B is a malicious server, it
has no chance to use ReadProcessMemory() if A gives B the own process
handle with only PROCESS_DUP_HANDLE access.

What is the problem here?
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.