Hi,
Is there any way to close a handle obtained by a
user-mode program to a driver from the driver itself?
If not is there any way to work around this, so that
the driver can tell 1 instance of a user-mode program
to close its handle when another instance of the
user-mode program is started?
Thanks
Krishna Monian
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
On Wed, 9 Jun 2004 17:20:34 -0700 (PDT), Krishna Monian
wrote:
> Hi,
>
> Is there any way to close a handle obtained by a
> user-mode program to a driver from the driver itself?
>
While running at PASSIVE_LEVEL in the context of any thread
of the user-mode program, call ZwCloseHandle on the handle.
Beware that the program is probably going to be quite
confused by loosing its handle.
Security Warning: Beware that you must find a way to ensure
that you are closing the right handle, and not a handle to
something else that some bad guy wants closed.
There are two problems: 1. Your driver has the power to close
handles that the user may be denied access to be the security
system, 2. Between the time that you identify the proper handle
and the time when your thread of execution enters into the
ZwCloseHandle call, some other thread might close the handle and
open another handle with the same numeric value but pointing to
something entirely different.
Unless the closing is done to allow your driver to be unloaded
or your device object to be destroyed, a better option is to
keep some per handle data structure (using the FILE_OBJECT in
the Irp), and then ignore any requests coming from the old
instance of the user mode program. That way you can also make
more sofisticated distinctions, such as still handling some
requests from the old instance or handling them differently
than for the new instance.
> If not is there any way to work around this, so that
> the driver can tell 1 instance of a user-mode program
> to close its handle when another instance of the
> user-mode program is started?
>
Jakob
–
#include <disclaimer.h></disclaimer.h>
Is there a way for the driver to keep track of the
handle it wants active.
Currently my user-mode program uses the CreateFile
routine to get a handle. It then sends a IOCTL to
start of a process. When another instance of the
user-mode program tries to get a handle, I want the
first handle to be invlidated.
The problem I am currently facing is, how do I keep
track of the active handle in the driver.
Can the driver get hold of the handle when the
user-mode program is given a handle through
CreateFile?
Or does the user mode program have to send in the
handle when it first sends an IOCTL? I could define a
separate IOCTL for this purpose.
Thanks
— Jakob Bohm wrote:
> On Wed, 9 Jun 2004 17:20:34 -0700 (PDT), Krishna
> Monian
> wrote:
>
> > Hi,
> >
> > Is there any way to close a handle obtained by a
> > user-mode program to a driver from the driver
> itself?
> >
>
> While running at PASSIVE_LEVEL in the context of any
> thread
> of the user-mode program, call ZwCloseHandle on the
> handle.
> Beware that the program is probably going to be
> quite
> confused by loosing its handle.
>
> Security Warning: Beware that you must find a way
> to ensure
> that you are closing the right handle, and not a
> handle to
> something else that some bad guy wants closed.
>
> There are two problems: 1. Your driver has the power
> to close
> handles that the user may be denied access to be the
> security
> system, 2. Between the time that you identify the
> proper handle
> and the time when your thread of execution enters
> into the
> ZwCloseHandle call, some other thread might close
> the handle and
> open another handle with the same numeric value but
> pointing to
> something entirely different.
>
>
> Unless the closing is done to allow your driver to
> be unloaded
> or your device object to be destroyed, a better
> option is to
> keep some per handle data structure (using the
> FILE_OBJECT in
> the Irp), and then ignore any requests coming from
> the old
> instance of the user mode program. That way you can
> also make
> more sofisticated distinctions, such as still
> handling some
> requests from the old instance or handling them
> differently
> than for the new instance.
>
>
> > If not is there any way to work around this, so
> that
> > the driver can tell 1 instance of a user-mode
> program
> > to close its handle when another instance of the
> > user-mode program is started?
> >
>
> Jakob
>
> –
> #include <disclaimer.h>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/</disclaimer.h>
On Thu, 10 Jun 2004 05:53:17 -0700 (PDT), Krishna Monian
wrote:
In the driver world, you normally don’t track the
handles themselves, but the matching FILE_OBJECTs
The main difference is, that if a program uses
DuplicateHandle or lets a handle be inherited by
child processes etc., this still only counts as
one FILE_OBJECT.
Rule of thumb: CreateFile always creates a FILE_OBJECT
in memory, that FILE_OBJECT may be associated with
a new or existing disk file, or with something entirely
different, but it does create a new FILE_OBJECT.
The FILE_OBJECT, like most kernel objects (EVENT, MUTEX,
DRIVER_OBJECT, DEVICE_OBJECT…) will be freed by the
Object Manager (ObXxxx ntoskrnl functions) when the last
handle has been freed with ZwCloseHandle and the last kernel
mode pointer reference has been released with ObDereferenceObject.
As a side effect of freeing the FILE_OBJECT from memory,
your driver will be called with IRP_MJ_DESTROY, so you can
clean up any data you may be keeping yourself.
So the solution:
In your device extension structure, add a field:
FILE_OBJECT *pCurrentUserFObj;
and initialize to NULL.
When you get the user mode IOCTL from an authorized process
just do
if (Irp->???.FileObject == NULL)
fail this call!
pDeviceExt->pCurrentUserFObj = Irp->???.FileObject;
pDeviceExt->any other stuff to remember = Irp->otherstuff
DON’T call ObReferenceObject!, that would prevent it from ever
being freed. The FILE_OBJECT references your driver, not the
other way around.
When you get IRP_MJ_CLOSE or IRP_MJ_DESTROY (check in
both handlers) do
if (pDeviceExt->pCurrentUserFObj == Irp->???.FileObject)
{
pDeviceExt->pCurrentUserFObj = NULL;
pDeviceExt->any other stuff to remember = NULL;
}
And to check if other Irps are from the current app:
if (pDeviceExt->pCurrentUserFObj == Irp->???.FileObject &&
pDeviceExt->pCurrentUserFObj != NULL)
{
It’s him, hurray
}
> Is there a way for the driver to keep track of the
> handle it wants active.
>
> Currently my user-mode program uses the CreateFile
> routine to get a handle. It then sends a IOCTL to
> start of a process. When another instance of the
> user-mode program tries to get a handle, I want the
> first handle to be invlidated.
>
> The problem I am currently facing is, how do I keep
> track of the active handle in the driver.
>
> Can the driver get hold of the handle when the
> user-mode program is given a handle through
> CreateFile?
>
> Or does the user mode program have to send in the
> handle when it first sends an IOCTL? I could define a
> separate IOCTL for this purpose.
>
> Thanks
>
>
>
> — Jakob Bohm wrote:
>> On Wed, 9 Jun 2004 17:20:34 -0700 (PDT), Krishna
>> Monian
>> wrote:
>>
>> > Hi,
>> >
>> > Is there any way to close a handle obtained by a
>> > user-mode program to a driver from the driver
>> itself?
>> >
>>
>> While running at PASSIVE_LEVEL in the context of any
>> thread
>> of the user-mode program, call ZwCloseHandle on the
>> handle.
>> Beware that the program is probably going to be
>> quite
>> confused by loosing its handle.
>>
>> Security Warning: Beware that you must find a way
>> to ensure
>> that you are closing the right handle, and not a
>> handle to
>> something else that some bad guy wants closed.
>>
>> There are two problems: 1. Your driver has the power
>> to close
>> handles that the user may be denied access to be the
>> security
>> system, 2. Between the time that you identify the
>> proper handle
>> and the time when your thread of execution enters
>> into the
>> ZwCloseHandle call, some other thread might close
>> the handle and
>> open another handle with the same numeric value but
>> pointing to
>> something entirely different.
>>
>>
>> Unless the closing is done to allow your driver to
>> be unloaded
>> or your device object to be destroyed, a better
>> option is to
>> keep some per handle data structure (using the
>> FILE_OBJECT in
>> the Irp), and then ignore any requests coming from
>> the old
>> instance of the user mode program. That way you can
>> also make
>> more sofisticated distinctions, such as still
>> handling some
>> requests from the old instance or handling them
>> differently
>> than for the new instance.
>>
>>
>> > If not is there any way to work around this, so
>> that
>> > the driver can tell 1 instance of a user-mode
>> program
>> > to close its handle when another instance of the
>> > user-mode program is started?
>> >
>>
>> Jakob
>>
>> –
>> #include <disclaimer.h>
>>
>> —
>> Questions? First check the IFS FAQ at
>> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as:
>> xxxxx@yahoo.com
>> To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Friends. Fun. Try the all-new Yahoo! Messenger.
> http://messenger.yahoo.com/
>
–
#include <disclaimer.h></disclaimer.h></disclaimer.h>
That was very informative and helpful. I had been
trying to figure out how CreateFile works for a while.
Thanks a lot.
— Jakob Bohm wrote:
> On Thu, 10 Jun 2004 05:53:17 -0700 (PDT), Krishna
> Monian
> wrote:
>
> In the driver world, you normally don’t track the
> handles themselves, but the matching FILE_OBJECTs
> The main difference is, that if a program uses
> DuplicateHandle or lets a handle be inherited by
> child processes etc., this still only counts as
> one FILE_OBJECT.
>
> Rule of thumb: CreateFile always creates a
> FILE_OBJECT
> in memory, that FILE_OBJECT may be associated with
> a new or existing disk file, or with something
> entirely
> different, but it does create a new FILE_OBJECT.
>
> The FILE_OBJECT, like most kernel objects (EVENT,
> MUTEX,
> DRIVER_OBJECT, DEVICE_OBJECT…) will be freed by
> the
> Object Manager (ObXxxx ntoskrnl functions) when the
> last
> handle has been freed with ZwCloseHandle and the
> last kernel
> mode pointer reference has been released with
> ObDereferenceObject.
> As a side effect of freeing the FILE_OBJECT from
> memory,
> your driver will be called with IRP_MJ_DESTROY, so
> you can
> clean up any data you may be keeping yourself.
>
>
> So the solution:
>
> In your device extension structure, add a field:
>
> FILE_OBJECT *pCurrentUserFObj;
>
> and initialize to NULL.
>
> When you get the user mode IOCTL from an authorized
> process
> just do
> if (Irp->???.FileObject == NULL)
> fail this call!
>
> pDeviceExt->pCurrentUserFObj =
> Irp->???.FileObject;
> pDeviceExt->any other stuff to remember =
> Irp->otherstuff
>
> DON’T call ObReferenceObject!, that would prevent it
> from ever
> being freed. The FILE_OBJECT references your
> driver, not the
> other way around.
>
>
> When you get IRP_MJ_CLOSE or IRP_MJ_DESTROY (check
> in
> both handlers) do
> if (pDeviceExt->pCurrentUserFObj ==
> Irp->???.FileObject)
> {
> pDeviceExt->pCurrentUserFObj = NULL;
> pDeviceExt->any other stuff to remember =
> NULL;
> }
>
> And to check if other Irps are from the current app:
> if (pDeviceExt->pCurrentUserFObj ==
> Irp->???.FileObject &&
> pDeviceExt->pCurrentUserFObj != NULL)
> {
> It’s him, hurray
> }
>
>
> > Is there a way for the driver to keep track of the
> > handle it wants active.
> >
> > Currently my user-mode program uses the CreateFile
> > routine to get a handle. It then sends a IOCTL to
> > start of a process. When another instance of the
> > user-mode program tries to get a handle, I want
> the
> > first handle to be invlidated.
> >
> > The problem I am currently facing is, how do I
> keep
> > track of the active handle in the driver.
> >
> > Can the driver get hold of the handle when the
> > user-mode program is given a handle through
> > CreateFile?
> >
> > Or does the user mode program have to send in the
> > handle when it first sends an IOCTL? I could
> define a
> > separate IOCTL for this purpose.
> >
> > Thanks
> >
> >
> >
> > — Jakob Bohm wrote:
> >> On Wed, 9 Jun 2004 17:20:34 -0700 (PDT), Krishna
> >> Monian
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > Is there any way to close a handle obtained by
> a
> >> > user-mode program to a driver from the driver
> >> itself?
> >> >
> >>
> >> While running at PASSIVE_LEVEL in the context of
> any
> >> thread
> >> of the user-mode program, call ZwCloseHandle on
> the
> >> handle.
> >> Beware that the program is probably going to be
> >> quite
> >> confused by loosing its handle.
> >>
> >> Security Warning: Beware that you must find a
> way
> >> to ensure
> >> that you are closing the right handle, and not a
> >> handle to
> >> something else that some bad guy wants closed.
> >>
> >> There are two problems: 1. Your driver has the
> power
> >> to close
> >> handles that the user may be denied access to be
> the
> >> security
> >> system, 2. Between the time that you identify the
> >> proper handle
> >> and the time when your thread of execution enters
> >> into the
> >> ZwCloseHandle call, some other thread might close
> >> the handle and
> >> open another handle with the same numeric value
> but
> >> pointing to
> >> something entirely different.
> >>
> >>
> >> Unless the closing is done to allow your driver
> to
> >> be unloaded
> >> or your device object to be destroyed, a better
> >> option is to
> >> keep some per handle data structure (using the
> >> FILE_OBJECT in
> >> the Irp), and then ignore any requests coming
> from
> >> the old
> >> instance of the user mode program. That way you
> can
> >> also make
> >> more sofisticated distinctions, such as still
> >> handling some
> >> requests from the old instance or handling them
> >> differently
> >> than for the new instance.
> >>
> >>
> >> > If not is there any way to work around this, so
> >> that
> >> > the driver can tell 1 instance of a user-mode
> >> program
> >> > to close its handle when another instance of
> the
> >> > user-mode program is started?
> >> >
> >>
> >> Jakob
> >>
> >> –
> >> #include <disclaimer.h>
> >>
> >> —
> >> Questions? First check the IFS FAQ at
> >> https://www.osronline.com/article.cfm?id=17
> >>
> >> You are currently subscribed to ntfsd as:
> >> xxxxx@yahoo.com
> >> To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
> >
> >
>
=== message truncated ===
__________________________________
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/</disclaimer.h>
> The problem I am currently facing is, how do I keep
track of the active handle in the driver.
Keep track of active file objects using the FsContext2 field. It can point to
any driver-specific data.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com