handle protection - please comment

egor duda deo@logos-m.ru
Wed Apr 18 03:48:00 GMT 2001


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
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 ();
to scan process' B handles in hope to find hMainProcess handle. And i
bet it won't take long to find it.

My point is that we shouldn't allow process A to obtain this handle
hProcessB, no matter what permissions we set to it, if process A is not
running in 'Administrator' security context. 

If you can suggest any other way to pass handles from process A (run
by user User1) to process B (run by user User2) without having server
run by administrator, it would be great.

As for now, we have _huge_ security hole in cygwin which allows any
local user to gain administrative privileges, as long as any cygwin
program is run by LocalSystem or Administrator.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

More information about the Cygwin-developers mailing list