I’m hoping to seek some clarification regarding driver initiated file I/O.
If Driver A is in the ?Anti-Virus? load order group and Driver B is in the ?Continuous Backup? group, Driver A will handle the pre-IRP_MJ_CREATE before Driver B.
So if Driver A then needs to open that file, it can use the FltCreateFile() routine to insure it?s open only goes to drivers below it in the stack. So when Driver A opens the file, that open will then go through to Driver B. Driver B then has the chance to backup the file prior to it being opened (I realize this may not be a real world example but bear with me).
However, shouldn?t Driver A be able to insure the file is safe before allowing the open to go to the backup driver (Driver B)? Isn?t this why Anti-Virus is near the top so it has a chance at scanning the files before lower-level drivers get a crack at it? However, I?m not seeing it that way so I must be missing something.
Also, how do legacy drivers fit in? Are they always above the FltMgr so they then above a Mini-Filter?
Any clarification would be great! Thanks in advance.
In general it isn’t a security risk, but it depends on what the backup
filter (or any filter) is doing. Just opening a file and treating it as an
opaque blob should be safe. If the driver tries to parse the file (or do
something like execute instructions from it) then it opens itself to
exploitation. This is why filter should do funky stuff that involves file
contents from user mode.
Also, the alternative would be that the AV filter is below the backup
filter, which means that if the backup filter is implemented in such a way
that data is retrieved on demand then the AV minifilter doesn’t have
anything to scan in Create. Also, consider an implementation where the
backup filter retrieves the data from the backup store but delays writing it
to the FS. In this case the actual data might not even make it to the FS
until after the file has be executed by user mode code.
In general, you want your AV filter to be higher than any type of filter
that might introduce data into the system (decryption, back-up, HSM and so
on), in order to be sure that all the data that will be returned to the user
can be seen by the AV filter.
Legacy filters are loaded differently depending on the OS version. Pre Vista
they will be attached in the order in which they are loaded while in Vista
and newer FltMgr will try to guess the altitude corresponding to the filter
and adjust its frames accordingly.
This might be interesting as well :
http://fsfilters.blogspot.com/2010/02/filter-manager-concepts-part-4.html.
There is a picture (about 1000 words worth :)) that shows how FltMgr
concepts and legacy filters fit into the FS filtering picture.
Thanks,
Alex.
Great info Alex - The 2nd and 3rd paragraphs clarified things quite a bit for me - thanks!
Our driver essentially “introduces” data so I believe we want to be lower in the stack.
We copy files down on-demand. Thus, I was under the impression we should be above most filter drivers (i.e. At Activity Monitor) so we can get the pre-Create first and copy down the data. However, like you stated, that would only lead to a AV filter scanning essentially nothing.
We really need to be lower so when the AV filter gets to actually doing the scan, real valid data exists in the file. Yes, the AV filter gets the pre-Create before we do, but their open will propagate down to our driver so we can provide actual data for the AV filter.
Let me know if I’m wrong!
You are right, you should be below AV.
You need to request an altitude for you filter from the filter manager team
and when you request it you need to tell them what group you need to be in.
If you want to discuss what that group is we can take it offline.
Thanks,
Alex.
Thanks Alex. We actually already have an altitude and fortuntely, although I was incorrect in how I thought things worked, in the end I got lucky and it’s within the right group.
Thanks for the link as well. It looks like you have a lot of posts worth reading! I wish I knew about them earlier! 
g (no space) weber -at- tricerat
(dot com at the end abviously)