Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <13327115627.20010418144700@logos-m.ru> To: "Robert Collins" CC: "Corinna Vinschen" Subject: Re: handle protection - please comment In-reply-To: <00a401c0c7f0$02bb1f30$0200a8c0@lifelesswks> References: <20010418120530 DOT Q15962 AT cygbert DOT vinschen DOT de> <00a401c0c7f0$02bb1f30$0200a8c0 AT lifelesswks> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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