Mail Archives: cygwin-developers/2001/04/18/11:37:56
On Wed, Apr 18, 2001 at 07:04:08PM +0400, egor duda wrote:
> Wednesday, 18 April, 2001 Corinna Vinschen vinschen AT redhat DOT 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
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
- Raw text -