www.delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/04/18/06:48:21

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
Date: Wed, 18 Apr 2001 14:47:00 +0400
From: egor duda <deo AT logos-m DOT ru>
X-Mailer: The Bat! (v1.45) Personal
Reply-To: egor duda <cygwin-developers AT cygwin DOT com>
Organization: deo
X-Priority: 3 (Normal)
Message-ID: <13327115627.20010418144700@logos-m.ru>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
CC: "Corinna Vinschen" <cygwin-developers AT cygwin DOT com>
Subject: Re: handle protection - please comment
In-reply-To: <00a401c0c7f0$02bb1f30$0200a8c0@lifelesswks>
References: <EA18B9FA0FE4194AA2B4CDB91F73C0EF79C2 AT itdomain002 DOT itdomain DOT net DOT au>
<20010418120530 DOT Q15962 AT cygbert DOT vinschen DOT de>
<00a401c0c7f0$02bb1f30$0200a8c0 AT lifelesswks>
Mime-Version: 1.0

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.

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019