handle protection - please comment

egor duda deo@logos-m.ru
Wed Apr 18 09:55:00 GMT 2001


Wednesday, 18 April, 2001 Corinna Vinschen vinschen@redhat.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

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=<some pid>'
and blocks waiting for input.

then switch to admin account and run '/tmp/t.exe <slave_pid>'
it'll print 'master handle=<handle1> object handle=<handle2>'

switch back to client account and input <handle1> and <handle2>

now look what /tmp/secret contains.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19

-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.c
Type: text/x-c
Size: 1911 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-developers/attachments/20010418/a9def223/attachment.bin>

More information about the Cygwin-developers mailing list