handle protection - please comment

Corinna Vinschen vinschen@redhat.com
Wed Apr 18 08:37:00 GMT 2001

On Wed, Apr 18, 2001 at 07:04:08PM +0400, egor duda wrote:
> Wednesday, 18 April, 2001 Corinna Vinschen vinschen@redhat.com wrote:
> >> the problem is that if i (process B) have handle of process with only
> >> PROCESS_DUP_HANDLE access, and process A have at least one private
> >> handle of itself with full access, i can elevate my privileges
> >> using the code quoted above. for cygwin programs the second thing is
> >> true -- every process has hMainProcess handle of itself. It won't give
> >> it to me, sure, but i can just try to guess it. i'll start duplicating
> >> all values 0x4,0x8,0xc,0x10,... (remember, i can duplicate handles
> >> from process  A), and sooner or later i'll find hMainProcess. voila,
> >> process B have all access to process' A address space.
> CV> I see. But that's a Cygwin specific problem only, AFAICS. Since
> CV> `_dll_crt0' creates hMainProc as a duplicate of `GetCurrentProcess()'
> CV> all processes have a real process handle to itself with full access
> CV> rights which could be duplicated by other processes. I'm not sure
> CV> why this is done because the return value of `GetCurrentProcess()'
> CV> should fit our needs and it can neither be duplicated nor used by
> CV> other processes.
> 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()

Uhm, ok, but from my point of view it's an academic problem.
The PROCESS_DUP_HANDLE permission on a process handle does _not_
open up the other handles of a process if the access rights of
these handles are set using appropriate values.

For example process A has a handle H with ALL_ACCESS for the user
of A and with R/O for the world. Giving it's process handle to
process B of another user doesn't allow suddenly R/W access to
process B. The user of B doesn't have that permission. So he's
stuck at that point. It's in the responsibility of process A not
to open up it's resources to others.

For example the CreateProcess call in Cygwin already uses
specific security setting in a fork() call. I don't say that
they are really good or sufficient for high security needs but
they are used and they could be refined.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

More information about the Cygwin-developers mailing list