Strange behavior of McAfee antivirus filter (naiavf5x.sys)

OSR_Community_User · March 29, 2005, 7:29am

Hi, all,

I have the following problem when my online encryption filter
runs together with McAfee VirusScan (naiavf5x.sys, version 7.1.0.111)
on NTFS (Windows 2000, probably XP too)

Note that I’m not asking for an advice, I rather would like to know
your opinion. Who does it wrong - MyFilter or the AV ?

The problem occurs when the CopyFile API copies an unencrypted file
to a place where the file gets encrypted. Here is the time-line of the
requests coming to the target file

IRP_MJ_CREATE issued by NtCreateFile. The target file doesn’t
exist, so it will be created new.
Two IRP_MJ_QUERY_INFORMATIONs, issued by the
naiavf5x.sys
IRP_MJ_SET_INFORMATION (FileEndOfFileInformation)
(issued by CopyFile). The file size will be incremented by MyFilter
to include the file tail. The file tail contains info about file
encryption.
The filter writes the file tail using my own generated IRP
(paging I/O write). This leads to NtfsCommonWrite
NtfsCommonWrite calls NtfsZeroData, which calls CcZeroData,
which calls another, recursive IRP_MJ_WRITE.
Naiavf5x.sys issues IRP_MJ_SET_INFORMATION
(FileEndOfFileInformation) which increases the file size *AGAIN*.
This is probably because the AV tries to fix it,
or wants to keep the file consistent or something.
IRP_MJ_WRITE (cached) - writing the file data
Issued by NtWriteFile
etc. (not important to the problem)

The result is that every CopyFile from normal to encrypted file
increases the file data by the size of one file tail, because
the size is incremented by the 6). The space is filled by zeros.

I think the AV behaves wrong, it should simply ignore the write
request in 5) and send it down. What do you mean ?

L.

OSR_Community_User · March 30, 2005, 2:07am

I have found why the problem comes.

In the point 3), where my filter adjusts the file size,
it does something like

PFILE_END_OF_FILE_INFORMATION EndOfFileInfo;

EndOfFileInfo = (cast)Irp->AssociatedIrp.SystemBuffer;
EndOfFileInfo->EndOfFile = IncrementedFileSize;

return CallLowerDriver(LowerDevice, Irp);

But after point 6), the naiavf5x.sys sends the same IRP
(IRP_MJ_SET_INFORMATION) again. The file size
in the EndOfFileInfo has already been incremented by my filter.
So the file size will be incremented twice.

So a good advice for all who write data modification
filters is:

If you change the file size in FILE_END_OF_FILE_INFO
structure coming with the IRP, you should restore the original value
after the IRP’s been completed.
This certainly applies to another structures for SetInfo as well.

L.

----- Original Message -----
From: “Ladislav Zezula”
To: “Windows File Systems Devs Interest List”
Sent: Tuesday, March 29, 2005 2:27 PM
Subject: [ntfsd] Strange behavior of McAfee antivirus filter (naiavf5x.sys)

> Hi, all,
>
> I have the following problem when my online encryption filter
> runs together with McAfee VirusScan (naiavf5x.sys, version 7.1.0.111)
> on NTFS (Windows 2000, probably XP too)
>
> Note that I’m not asking for an advice, I rather would like to know
> your opinion. Who does it wrong - MyFilter or the AV ?
>
> The problem occurs when the CopyFile API copies an unencrypted file
> to a place where the file gets encrypted. Here is the time-line of the
> requests coming to the target file
>
> 1) IRP_MJ_CREATE issued by NtCreateFile. The target file doesn’t
> exist, so it will be created new.
>
> 2) Two IRP_MJ_QUERY_INFORMATIONs, issued by the
> naiavf5x.sys
>
> 3) IRP_MJ_SET_INFORMATION (FileEndOfFileInformation)
> (issued by CopyFile). The file size will be incremented by MyFilter
> to include the file tail. The file tail contains info about file
> encryption.
>
> 4) The filter writes the file tail using my own generated IRP
> (paging I/O write). This leads to NtfsCommonWrite
>
> 5) NtfsCommonWrite calls NtfsZeroData, which calls CcZeroData,
> which calls another, recursive IRP_MJ_WRITE.
>
> 6) Naiavf5x.sys issues IRP_MJ_SET_INFORMATION
> (FileEndOfFileInformation) which increases the file size AGAIN.
> This is probably because the AV tries to fix it,
> or wants to keep the file consistent or something.
>
> 7) IRP_MJ_WRITE (cached) - writing the file data
> Issued by NtWriteFile
>
> 8) etc. (not important to the problem)
>
> The result is that every CopyFile from normal to encrypted file
> increases the file data by the size of one file tail, because
> the size is incremented by the 6). The space is filled by zeros.
>
> I think the AV behaves wrong, it should simply ignore the write
> request in 5) and send it down. What do you mean ?
>
> L.

OSR_Community_User · March 30, 2005, 8:50pm

I have no this problem,because my way can avoid it:
If a IRP_MJ_CREATE come,I will know it’s a CreateNewFile,so I just encrypt
it’s contents.
OK,I need add a tail after the file ,so,When IRP_MJ_CLEANUP comes,I will
add it.
In memory,I record these information,including: what fileobject is
encrypted(or need encrypted),so,when the IRP_MJ_CLEANUP comes,I can know I
should add a tail.
In these way,I don’t care SetInfo.

From: “Ladislav Zezula”
>Reply-To: “Windows File Systems Devs Interest List”
>To: “Windows File Systems Devs Interest List”
>Subject: Re: [ntfsd] Strange behavior of McAfee antivirus filter
(naiavf5x.sys)
>Date: Wed, 30 Mar 2005 09:05:06 +0200
>
>I have found why the problem comes.
>
>In the point 3), where my filter adjusts the file size,
>it does something like
>
>---------
>PFILE_END_OF_FILE_INFORMATION EndOfFileInfo;
>
>EndOfFileInfo = (cast)Irp->AssociatedIrp.SystemBuffer;
>EndOfFileInfo->EndOfFile = IncrementedFileSize;
>
>return CallLowerDriver(LowerDevice, Irp);
>----------
>
>But after point 6), the naiavf5x.sys sends the same IRP
>(IRP_MJ_SET_INFORMATION) again. The file size
>in the EndOfFileInfo has already been incremented by my filter.
>So the file size will be incremented twice.
>
>So a good advice for all who write data modification
>filters is:
>
>If you change the file size in FILE_END_OF_FILE_INFO
>structure coming with the IRP, you should restore the original value
>after the IRP’s been completed.
>This certainly applies to another structures for SetInfo as well.
>
>L.
>
>----- Original Message ----- From: “Ladislav Zezula”
>
>To: “Windows File Systems Devs Interest List”
>Sent: Tuesday, March 29, 2005 2:27 PM
>Subject: [ntfsd] Strange behavior of McAfee antivirus filter
>(naiavf5x.sys)
>
>
>>Hi, all,
>>
>>I have the following problem when my online encryption filter
>>runs together with McAfee VirusScan (naiavf5x.sys, version
>>7.1.0.111)
>>on NTFS (Windows 2000, probably XP too)
>>
>>Note that I’m not asking for an advice, I rather would like to know
>>your opinion. Who does it wrong - MyFilter or the AV ?
>>
>>The problem occurs when the CopyFile API copies an unencrypted file
>>to a place where the file gets encrypted. Here is the time-line of
>>the
>>requests coming to the target file
>>
>>1) IRP_MJ_CREATE issued by NtCreateFile. The target file doesn’t
>> exist, so it will be created new.
>>
>>2) Two IRP_MJ_QUERY_INFORMATIONs, issued by the
>> naiavf5x.sys
>>
>>3) IRP_MJ_SET_INFORMATION (FileEndOfFileInformation)
>> (issued by CopyFile). The file size will be incremented by
>>MyFilter
>> to include the file tail. The file tail contains info about
>>file encryption.
>>
>>4) The filter writes the file tail using my own generated IRP
>> (paging I/O write). This leads to NtfsCommonWrite
>>
>>5) NtfsCommonWrite calls NtfsZeroData, which calls CcZeroData,
>> which calls another, recursive IRP_MJ_WRITE.
>>
>>6) Naiavf5x.sys issues IRP_MJ_SET_INFORMATION
>> (FileEndOfFileInformation) which increases the file size
>>AGAIN.
>> This is probably because the AV tries to fix it,
>> or wants to keep the file consistent or something.
>>
>>7) IRP_MJ_WRITE (cached) - writing the file data
>> Issued by NtWriteFile
>>
>>8) etc. (not important to the problem)
>>
>>The result is that every CopyFile from normal to encrypted file
>>increases the file data by the size of one file tail, because
>>the size is incremented by the 6). The space is filled by zeros.
>>
>>I think the AV behaves wrong, it should simply ignore the write
>>request in 5) and send it down. What do you mean ?
>>
>>L.
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@hotmail.com
>To unsubscribe send a blank email to
>xxxxx@lists.osr.com

_________________________________________________________________
ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓÊ¼þÏµÍ³¡ª MSN Hotmail¡£ http://www.hotmail.com

OSR_Community_User · March 31, 2005, 1:18am

I agree with you, but our approach tries to keep the
file consistent as much as possible. So the file tail
is added after each file size increase. Maybe your
approach is faster, maybe our approach is safer.
I can’t exactly say what is better.

L.