pass kernel mode file handle to user mode app

NTFSD
1

Hi,

in my minifilter driver I open a file using FltCreateFile in the pre-create and pre-cleanup callbacks; I would like to use this / or a duplicated handle in a user mode application (which is invoked by the driver and processes the file); how can I use this handle in a given user mode process? (if I simply pass it it fails with ERROR_INVALID_HANDLE, as it is expected)
what are the steps needed to pass this handle to the given user mode process?

thank you very much,

Alex

2

You can pass handles back and forth as long as they belong to the same process context. In your DriverEntry() you are in the context of the System process. And since a filter driver runs its dispatch routines in an arbitrary context … :-\ …

However, I dare say this is not quite how it should be. I am not sure whether you open security holes by using this method. Also a usermode application invoked by a driver does not sound very security-aware either.

Any frequent reader of www.rootkit.com is aware that there are indeed methods to do this, but the domain name should give a clue for what these methods are usually used.

Hope I did not misunderstand something …

Best regards,

Oliver

–

May the source be with you, stranger :wink:

ICQ: #281645
URL: http://assarbad.info | http://windirstat.info | http://blog.assarbad.info

3

hi,

I’m actually not working either on security holes (???) nor on rootkits
(if I understood correctly, the you think some like this :-))
I’m actully working on a anti-virus minifilter driver and I have a driver
and a user mode scanner attached to it; now, the problem is that
for pre-vista OS-s I used to open the file directly from the user
mode scanner; that works ok; now, for vista & longhorn there are
transactions; and I didn’t figure out how to handle them correctly
(because of isolation); so, I tried to open the files using FltCreateFileEx2
(some kind of FltCreateFile) inside the driver, using the transaction
context! so, I’m practicly inside the transaction; now, I would like
to pass this handle to the user mode scanner process;
can you or anybody else help me to do this in a right way?

or, if this is not a good solution, can I open a file from user mode
inside an arbitrary transaction?

thanks in advance,

Alex

4

When your minifilter has determined that a file object is involved in a
transaction, the minifilter should then enlist and your minifilter will
then be a ‘participant’ in the transaction.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, September 01, 2006 8:51 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] pass kernel mode file handle to user mode app

hi,

I’m actually not working either on security holes (???) nor
on rootkits (if I understood correctly, the you think some
like this :-)) I’m actully working on a anti-virus minifilter
driver and I have a driver and a user mode scanner attached
to it; now, the problem is that
for pre-vista OS-s I used to open the file directly from the user
mode scanner; that works ok; now, for vista & longhorn there
are transactions; and I didn’t figure out how to handle them
correctly (because of isolation); so, I tried to open the
files using FltCreateFileEx2 (some kind of FltCreateFile)
inside the driver, using the transaction context! so, I’m
practicly inside the transaction; now, I would like to pass
this handle to the user mode scanner process; can you or
anybody else help me to do this in a right way?

or, if this is not a good solution, can I open a file from
user mode inside an arbitrary transaction?

thanks in advance,

Alex

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@iss.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

5

thank you; if I understand correctly, then this would permit the minifilter to read-write that particular file inside the transaction (correct me if I’m wrong); but, this would NOT allow the scanner open & read access to the file; what I want to achieve is to have access from a user mode scanner; any ideas?

thanks again,
Alex

6

Perhaps have your minifilter read/write the file on behalf of the user
mode app?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, September 01, 2006 9:03 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] pass kernel mode file handle to user mode app

thank you; if I understand correctly, then this would permit
the minifilter to read-write that particular file inside the
transaction (correct me if I’m wrong); but, this would NOT
allow the scanner open & read access to the file; what I want
to achieve is to have access from a user mode scanner; any ideas?

thanks again,
Alex

7

> You can pass handles back and forth as long as they belong to the same

process context

And they are not kernel handles.

And since a filter driver runs its dispatch routines in an arbitrary
context

Not alway true. The system always use the context of the caller for the
create/cleanup/read/writre/ioctl requests, only the FSD filters can change
the context. But the FSD filters must not defer processing in other threads
if the top level irp is not NULL, this leads to BSOD or dead lock. Also a
very bad idea for a filter to defer in other threads the cleanup and create
requests.

–
Slava Imameyev, xxxxx@hotmail.com

“Oliver Schneider” wrote in message
news:xxxxx@ntfsd…
> You can pass handles back and forth as long as they belong to the same
> process context. In your DriverEntry() you are in the context of the
> System process. And since a filter driver runs its dispatch routines in an
> arbitrary context … :-\ …
>
> However, I dare say this is not quite how it should be. I am not sure
> whether you open security holes by using this method. Also a usermode
> application invoked by a driver does not sound very security-aware either.
>
> Any frequent reader of www.rootkit.com is aware that there are indeed
> methods to do this, but the domain name should give a clue for what these
> methods are usually used.
>
> Hope I did not misunderstand something …
>
> Best regards,
>
> Oliver
>
> –
> ---------------------------------------------------
> May the source be with you, stranger :wink:
>
> ICQ: #281645
> URL: http://assarbad.info | http://windirstat.info |
> http://blog.assarbad.info
>

8

yes, that IS another solution, but is too complicated; so, I could create a differen I/O path (for ex. using device IOCTLs) to replace the standard CreateFile/ReadFile Win32 sequence used currently by the scanner, this shall work; but the problem is, that this would require a quite serious rewrite of the scanner interface; and that is to be avoided to the maximum if possible (this is some kind of must-to requirement, there are actually several scanners above the current driver);

so, I think, there shall be some way to pass / duplicate (maybe with ZwDuplicateObject??) that handle to be usable under user mode scanner process; I found some related stuff, but the whole thing is not clear; any idea? article? link? example?

thank you very much,

Alex

9

OK…but it seems (to me anyway) it is probably less of an impact/risk
then relying on APIs that are ‘reserved for system use’…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, September 01, 2006 9:18 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] pass kernel mode file handle to user mode app

yes, that IS another solution, but is too complicated; so, I
could create a differen I/O path (for ex. using device
IOCTLs) to replace the standard CreateFile/ReadFile Win32
sequence used currently by the scanner, this shall work; but
the problem is, that this would require a quite serious
rewrite of the scanner interface; and that is to be avoided
to the maximum if possible (this is some kind of must-to
requirement, there are actually several scanners above the
current driver);

so, I think, there shall be some way to pass / duplicate
(maybe with ZwDuplicateObject??) that handle to be usable
under user mode scanner process; I found some related stuff,
but the whole thing is not clear; any idea? article? link? example?

thank you very much,

Alex

10

wrote in message news:xxxxx@ntfsd…
>
> so, I think, there shall be some way to pass / duplicate (maybe with
> ZwDuplicateObject??) that handle to be usable under user mode scanner
> process; I found some related stuff, but the whole thing is not clear; any
> idea? article? link? example?
>
Since this will open a security hole of immense proportions, go look at the
hackers sites. Bottom line, is you are using the kernel to bypass all
security checking then handing the access up to a program that you cannot be
sure is safe. It is way to easy to hijack the scanner application, exploit
this hole.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply

11

>but the problem is, that this would require a quite serious rewrite of the

scanner interface; and that is to be avoided

I would try to implement a sort “proxy-device” that forwards every IRP to
your file-object “handle”. In this case all you do have to change is the
filename that your user-mode scanner uses to open that file…replace it
with the name of your proxy device. Even consider to go one step further:
do not forward the handle you got from your FltCreateFile, but forward
(hijack) the handle you get in PostCreate from that thread trying to open
that file. The scanner-sample in IFS-Kit does the same.

Frank

schrieb im Newsbeitrag news:xxxxx@ntfsd…
> yes, that IS another solution, but is too complicated; so, I could create
> a differen I/O path (for ex. using device IOCTLs) to replace the standard
> CreateFile/ReadFile Win32 sequence used currently by the scanner, this
> shall work; but the problem is, that this would require a quite serious
> rewrite of the scanner interface; and that is to be avoided to the maximum
> if possible (this is some kind of must-to requirement, there are actually
> several scanners above the current driver);
>
> so, I think, there shall be some way to pass / duplicate (maybe with
> ZwDuplicateObject??) that handle to be usable under user mode scanner
> process; I found some related stuff, but the whole thing is not clear; any
> idea? article? link? example?
>
> thank you very much,
>
> Alex
>

12

>> You can pass handles back and forth as long as they belong to the same

> process context
And they are not kernel handles.

so, if I understand correctly, there is no chance to pass the original handle obtained
from FltCreateFileEx2 directly; only a duplicate one;

>And since a filter driver runs its dispatch routines in an arbitrary
>context
Not alway true. The system always use the context of the caller for the >create/cleanup/read/writre/ioctl requests, only the FSD filters can change the context.

the context of the caller is NOT the context of my scanner, but the context of an arbitrary user mode (or kernel mode) process; what I need is to duplicate / create a handle that is valid in the process context of my scanner

I tried to obtain a handle to my scanner process from a previous call to PsGetCurrentProcessId; but I’m not really sure, this is a HANDLE or a PID (the function is prototypes as returning HANDLE, but the WDK docs says that this is the process ID; if this is not a valid handle, I could use ObOpenObjectByPointer to obtain a handle to the scanner process?
similarly, I could obtain the process handle for the process in which’s context the file was opened in kernel mode; then, I could use ZwDuplicateObject to obtain a handle valid in the user mode scanner process? or this is not possible because the first handle was in kernel mode?

please help me, if you can,

Alex

13

>Since this will open a security hole of immense proportions, go look at the hackers sites. Bottom line, >is you are using the kernel to bypass all security checking then handing the access up to a program >that you cannot be sure is safe. It is way to easy to hijack the scanner application, exploit this hole.

– Don Burn (MVP, Windows DDK) Windows 2k/XP/2k3 Filesystem and Driver Consulting >http://www.windrvr.com Remove StopSpam from the email to reply

ok, I understand, so apparently this is NOT a good way to go (because one could easily hack the scanner app and so on)

thak you very much,

Alex

14

>I would try to implement a sort “proxy-device” that forwards every IRP to your file-object “handle”.

In this case all you do have to change is the filename that your user-mode scanner uses to open
that file…replace it with the name of your proxy device. Even consider to go one step further: do
not forward the handle you got from your FltCreateFile, but forward (hijack) the handle you get in
PostCreate from that thread trying to open that file. The scanner-sample in IFS-Kit does the same.

when you speak about forward / hijack, do you mean, that the IFS example is actually does NOT reopen the file using FltCreateFile, but reads the file dirrectly using the FileObject obtained for the arbitrary 3rd party user mode process?

so, this would mean, that I could detect in my open/read requests the cases, when the requestor is my scanner process, then handle those requests without forwarding down the request toward the FSD, but handling it directly by reading the original file using the file object obtained for the 3rd party process?

thank you very much,

Alex

Frank

15

> when you speak about forward / hijack, do you mean, that the IFS example

is actually does NOT reopen the file using FltCreateFile, but reads the
file dirrectly using the FileObject obtained for the arbitrary 3rd party
user mode process?

Bingo!

so, this would mean, that I could detect in my open/read requests the
cases, when the requestor is my scanner process, then handle those
requests without forwarding down the request toward the FSD, but handling
it directly by reading the original file using the file object obtained
for the 3rd party process?

Almost…I would not do my usermode-scanner-requests through my
mini-filter-callbacks. Just implement a device-object with various dispatch
routines, that act like a filesystem. Then feed your usermode-scanner
(CreateFile) with the name of that device. Implementation of such a device
could go like this:

NTSTATUS MyProxyDispatchRead(
IN PDEVICE_OBJECT DeviceObject,
IN PIRP Irp
)
{
PCFLT_RELATED_OBJECTS pForwardedFltObjects =
(PCFLT_RELATED_OBJECTS)IoGetCurrentIrpStackLocation(Irp)->FileObject->FsContext;

…
// avoid to update the hijacked file-object’s file pos pointer
status = FltReadFile(pForwardedFltObjects ->Instance,
pForwardedFltObjects ->FileObject,
&offset,
dwTotalSize,
pBuffer,
FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET,
&bytesRead,
NULL,
NULL );

…
}

schrieb im Newsbeitrag news:xxxxx@ntfsd…
> >I would try to implement a sort “proxy-device” that forwards every IRP to
> >your file-object “handle”.
>>In this case all you do have to change is the filename that your user-mode
>>scanner uses to open
>>that file…replace it with the name of your proxy device. Even consider
>>to go one step further: do
>>not forward the handle you got from your FltCreateFile, but forward
>>(hijack) the handle you get in
>>PostCreate from that thread trying to open that file. The scanner-sample
>>in IFS-Kit does the same.
>>
> when you speak about forward / hijack, do you mean, that the IFS example
> is actually does NOT reopen the file using FltCreateFile, but reads the
> file dirrectly using the FileObject obtained for the arbitrary 3rd party
> user mode process?
>
> so, this would mean, that I could detect in my open/read requests the
> cases, when the requestor is my scanner process, then handle those
> requests without forwarding down the request toward the FSD, but handling
> it directly by reading the original file using the file object obtained
> for the 3rd party process?
>
> thank you very much,
>
> Alex
>
>>
>>Frank
>
>
>

16

ObOpenObjectByPointer is a solution.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From:
To: “Windows File Systems Devs Interest List”
Sent: Friday, September 01, 2006 4:11 PM
Subject: [ntfsd] pass kernel mode file handle to user mode app

> Hi,
>
> in my minifilter driver I open a file using FltCreateFile in the pre-create
and pre-cleanup callbacks; I would like to use this / or a duplicated handle in
a user mode application (which is invoked by the driver and processes the
file); how can I use this handle in a given user mode process? (if I simply
pass it it fails with ERROR_INVALID_HANDLE, as it is expected)
> what are the steps needed to pass this handle to the given user mode process?
>
> thank you very much,
>
> Alex
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com