Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
Message-ID: <00ba01c0c7f6$530ac1b0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "egor duda" <cygwin-developers AT cygwin DOT com>
Cc: "Corinna Vinschen" <cygwin-developers AT cygwin DOT com>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79C2 AT itdomain002 DOT itdomain DOT net DOT au> <20010418120530 DOT Q15962 AT cygbert DOT vinschen DOT de> <00a401c0c7f0$02bb1f30$0200a8c0 AT lifelesswks> <13327115627 DOT 20010418144700 AT logos-m DOT ru>
Subject: Re: handle protection - please comment
Date: Wed, 18 Apr 2001 20:57:05 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 18 Apr 2001 10:49:46.0698 (UTC) FILETIME=[48B302A0:01C0C7F5]

----- 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