Win7 verifier

ben_tsang · April 26, 2012, 9:33pm

Hi,

I have two questions regarding to the driver verifier in windows 7.

If i open a file(in user mode instead of kernel mode,OBJ_KERNEL_HANDLE not set) with FltCreate in my filter and pass the handle to my user mode app, after process the file, the user mode app will close the handle,the file was closed completely(monitor from filespy). If i unload my filter now, the driver verifier will bugcheck said that i have one open file didn’t close.
If i open a file(in user mode instead of kernel mode) with FltCreate in my filter, then i close the file with FltClose in my filter, the driver verifier will bugcheck too said that i close user mode handle instead of the kernel handle.

So why the driver verifier will bugcheck these? What’s wrong with that?

Thanks for any input.

Tsang

OSR_Community_User · April 26, 2012, 11:08pm

> 1. If i open a file(in user mode instead of kernel mode,OBJ_KERNEL_HANDLE not set)

I don’t think it is ever a good idea.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

ben_tsang · April 27, 2012, 9:34am

Thanks Maxim.

If it is not a good idea, do you know how can i access a file with read/write access in my user mode
app which the file was opened with share null by another application?

Tsang

Peter_Scott · April 27, 2012, 10:10am

On 4/26/2012 7:33 PM, xxxxx@hotmail.com wrote:

Hi,

I have two questions regarding to the driver verifier in windows 7.

If i open a file(in user mode instead of kernel mode,OBJ_KERNEL_HANDLE not set) with FltCreate in my filter and pass the handle to my user mode app, after process the file, the user mode app will close the handle,the file was closed completely(monitor from filespy). If i unload my filter now, the driver verifier will bugcheck said that i have one open file didn’t close.

Kernel mode handles should not be passed to a user mode application for
closing. Kernel mode handles are just that, kernel mode. In doing this
you could leak access to a file to a user mode process which otherwise
couldn’t be accessed from that process.

If i open a file(in user mode instead of kernel mode) with FltCreate in my filter, then i close the file with FltClose in my filter, the driver verifier will bugcheck too said that i close user mode handle instead of the kernel handle.

The user mode handle is only valid in the context of the calling
process. Verifier is ensuring that you do not, in general, attempt to
pass around a user mode handle. Since in one process the handle may
represent foo while in another it could represent bar which can lead to
obvious cross-process leakage. Of course there is also the case of the
handle being completely invalid in one or the other contexts.

So why the driver verifier will bugcheck these? What’s wrong with that?

In general, verifier is ensuring that there is no leaked access for
either of the above cases. Which, in my opinion, is a good thing.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

ben_tsang · April 27, 2012, 11:24am

Thanks Pete,

For the first question, actually my user mode app send the request to my filter, my filter then open the file for user mode use instead of kernel mode, and it is in the user process context, then the user mode process close the handle.

Do you think it still has problem? If yes, what is the best way to access the file from my user mode app when it was opened with share null by other process?

Tsang

Alex_Carp · April 27, 2012, 12:16pm

Actually, I don’t see a problem with your scenario.

As far as I know the scenario that can create security holes is using a user mode handle in kernel mode. However, what you are doing (opening a file on behalf of a user-mode process) should be ok, provided that you never use that handle in your driver and that you don’t bypass other system security (if the user-mode process doesn’t have access to the file then you might be creating a security hole).

I believe that FltCreateFile actually tracks the files you’ve opened using the ActiveOpens member of the filter structure. On the other hand, this might be DriverVerifier actually tracking it.

So if my understanding is correct you have a user mode process that communicates to a minifilter that it wants to open a file and the minifilter opens the file for it. In this case you might be better off opening the file using ZwCreateFile in the minifilter instead of FltCreateFile, because you would be bypassing all the filters above yours and you might run into issues such as the name that you get from the user mode process might actually resolve to something else if you use FltCreateFile (if there are any virtualization filters on the stack) and also the file might be encrypted or AVs won’t scan it and so on. This should also help since I don’t think FltMgr will track your handle in this case.

I feel that I should also warn you that if someone has a file open and they don’t want to share it it most likely means that the file can’t be safely read or written to. For example, an application might open a file, read all the contents in memory, zero-out the on-disk contents and then only when it’s done with the file it will write the new contents in. In this case you might not find anything in the file, but there are other cases where the file structure might be wrong and so on. So if you are doing this for a backup solution (for example) then ignoring sharing is not a good idea since you’ll most likely end up with a broken backup…

Thanks,
Alex.

ben_tsang · April 27, 2012, 1:45pm

Hi Alex

Thank you so much for your detail explanation.

If what i did is ok, Is there a way to avoid the bug check from the driver verifier?

Tsang

OSR_Community_User · April 27, 2012, 3:27pm

> app which the file was opened with share null by another application?

Make a VSS snapshot and open file there.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Alex_Carp · April 27, 2012, 4:58pm

As I said, have you tried using ZwCreateFile ? Does verifier complain even then (I don’t expect it would) ?

Thanks,
Alex.

ben_tsang · April 27, 2012, 9:48pm

Thanks Alex,

As you said, if i use ZwCreateFile, i don’t get the verifier complain.

But it can’t solve my problem, since i can’t open the file when it was share null.

The file I need to open is my own stub file, so when someone try to read/write this file i need to restore the data back. That’s why i need to open the file with write access, I want to write back the
data to the file in my user app. So is there a way to implement this?

Thanks
Tsang

Alex_Carp · April 28, 2012, 11:34am

Ah sorry about that. IoCreateFile should allow you to specify the flag to ignore share access, just like FltCreateFile, while still not triggering any driver verifier bugcheck

Sent from my iPhone

On Apr 27, 2012, at 6:47 PM, xxxxx@hotmail.com wrote:

Thanks Alex,

As you said, if i use ZwCreateFile, i don’t get the verifier complain.

But it can’t solve my problem, since i can’t open the file when it was share null.

The file I need to open is my own stub file, so when someone try to read/write this file i need to restore the data back. That’s why i need to open the file with write access, I want to write back the
data to the file in my user app. So is there a way to implement this?

Thanks
Tsang

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

ben_tsang · April 28, 2012, 3:58pm

Thanks Alex,

I tried IoCreateFile with IO_NO_PARAMETER_CHECKING setting, it still doesn’t work.
Then i try to use IoCreateFileSpecifyDeviceObjectHint with IO_IGNORE_SHARE_ACCESS_CHECK, it works, verifier no complain now.

Tsang