This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: handle protection - please comment


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.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]