Mail Archives: cygwin-developers/2001/04/18/06:57:22
----- Original Message -----
From: "egor duda" <deo AT logos-m DOT ru>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: "Corinna Vinschen" <cygwin-developers AT cygwin DOT com>
Sent: Wednesday, April 18, 2001 8:47 PM
Subject: Re: handle protection - please comment
> Hi!
>
> Wednesday, 18 April, 2001 Robert Collins
robert DOT collins AT itdomain DOT com DOT 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.
Place them in a a list in a shared memory area. That is essentially what
kernels do. No process memory access is needed. I'm considering having
to do this to have mutexs in user shared memory areas work (rather than
pretend they do to userland, and fail silently which currently happens).
That list is then readable by anyone with appropriate permissions. That
shouldn't open a security hole because AFAICT the shared memory area can
be opened with current user-only write, everyone read permissions. As
the items in the list will not contain data, just handles and related
kernel state data we shouldn't allow process privilege escalations by
doing that.
Size of the area? I dunno, make it 64Kb - the minimum, and a linked list
of areas.
> 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 AT logos-m DOT ru ICQ 5165414 FidoNet
2:5020/496.19
yeah, that kinda hole we can do without :]
Rob
- Raw text -