Deleting a file from PostOpCreate

NTFSD
1

Hello,

I have a mini-filter that detects an infected file (on-access) and attempts to delete it from PostOpCreate. I am experimenting this with standard eicar signature.

When the infected file is detected on the readonly USB stick, the delete call initiated by my filter blocks forever. I am using FltSetInformationFile with FileDispositionInformation to delete the file. The relevant windbg output reveals the following.

Any thoughts on why this may be happening?

0: kd> !thread fffffa80039bc540
THREAD fffffa80039bc540 Cid 0794.0d38 Teb: 000007fffff5e000 Win32Thread: fffff900c06adc20 WAIT: (Executive) KernelMode Alertable
fffffa800414dc48 SynchronizationEvent
IRP List:
fffffa8004129010: (0006,0478) Flags: 00000884 Mdl: 00000000
Not impersonating
DeviceMap fffff8a001107600
Owning Process fffffa80045cfb30 Image: explorer.exe
Attached Process N/A Image: N/A
Wait Start TickCount 4377 Ticks: 1594 (0:00:00:24.906)
Context Switch Count 101 LargeStack
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address SHLWAPI!WrapperThreadProc (0x000007feff07c7d4)
Stack Init fffff88006212db0 Current fffff88006211e30
Base fffff88006213000 Limit fffff8800620b000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 2 IoPriority 2 PagePriority 2
Child-SP RetAddr : Args to Child : Call Site
fffff88006211e70 fffff800030d5222 : fffffa80039bc540 fffffa80039bc540 fffffa8000000000 0000000000000000 : nt!KiSwapContext+0x7a
fffff88006211fb0 fffff800030d758f : fffff8000349ac00 fffff800034fe6c0 fffffa8000000000 fffffa8004151770 : nt!KiCommitThreadWait+0x1d2
fffff88006212040 fffff8000336a2be : fffffa8004151700 fffffa8000000000 fffffa80038d7b00 0000000000000001 : nt!KeWaitForSingleObject+0x19f
fffff880062120e0 fffff8000336a247 : fffffa8004151ba0 fffff880062121c0 fffffa800414dc30 0000000000000000 : nt!FsRtlCancellableWaitForMultipleObjects+0x5e
fffff88006212140 fffff8800114a656 : fffffa800414dc48 fffffa8004151770 fffffa800238d001 fffffa80042d0010 : nt!FsRtlCancellableWaitForSingleObject+0x27
fffff88006212180 fffff8800114594a : 0000000000000000 0000000000000000 fffffa8004488c00 fffffa800414dc30 : fltmgr! ?? ::FNODOBFM::string'+0x2b89 fffff88006212210 fffff8800117bc1e : fffffa8004489bc0 000000000000001c fffffa80042d0010 fffffa800414dce0 : fltmgr!FltPerformSynchronousIo+0x2ca fffff880062122b0 fffff880011b4295 : 0000000000000000 fffffa80045abac0 fffffa800414eb30 fffffa80045abac0 : fltmgr!FltSetInformationFile+0xde fffff88006212310 fffff880011b441b : 0000000000000000 fffffa80045aba01 0000000000000000 fffff88000000000 : MYFILTER!DeleteFileUsingFileObject fffff88006212350 fffff880011ae7d9 : fffffa8000000000 fffffa80045abac0 ffffffff800005f0 fffffa800414eb30 : MYFILTER!DeleteFileUsingPath fffff880062123f0 fffff88001144242 : 0000000000000000 fffffa8004129440 0000000000000000 0000000000000000 : MYFILTER!PostOpCreate+0x645 fffff88006212530 fffff8800114338b : fffffa8002350770 fffffa8004129e00 fffffa8004488c60 fffffa8004488e80 : fltmgr!FltpPerformPostCallbacks+0x392 fffff88006212600 fffff880011622b9 : fffffa8004129010 fffffa80042d0010 fffffa8004129000 fffffa80042d9950 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x39b fffff88006212690 fffff800033cb947 : 0000000000000005 fffff800033cb3a0 fffffa800383b610 0000000000000000 : fltmgr!FltpCreate+0x2a9 fffff88006212740 fffff800033c2294 : fffffa80038d7bd0 0000000000000000 fffffa80028ccb10 0000000000000001 : nt!IopParseDevice+0x5a7 fffff880062128d0 fffff800033c6f8d : fffffa80028ccb10 fffff88006212a30 fffffa8000000040 fffffa80019349c0 : nt!ObpLookupObjectName+0x585 fffff880062129d0 fffff800033cda57 : 00000000000007ff 0000000000000001 fffff8a001a2c701 0000000000000000 : nt!ObOpenObjectByName+0x1cd fffff88006212a80 fffff800033d77e0 : 0000000002b0ddb8 fffff8a080100080 fffff8a0012aacd0 0000000002b0ddc8 : nt!IopCreateFile+0x2b7 fffff88006212b20 fffff800030cd293 : ffffffffffffffff 0000000000000001 0000000002b0d7b0 fffff80000000024 : nt!NtCreateFile+0x78 fffff88006212bb0 00000000771efc0a : 000007fefd424d76 0000000008000000 0000000080000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff88006212c20)
0000000002b0dd38 000007fefd424d76 : 0000000008000000 0000000080000000 0000000000000000 00000000002bc7e0 : ntdll!NtCreateFile+0xa
0000000002b0dd40 0000000077092aad : 0000000080000000 0000000080000000 0000ef2400000001 000007fefe433aec : KERNELBASE!CreateFileW+0x2cd
0000000002b0dea0 000007fefe438572 : 0000000000002000 0000000000000001 0000000008000000 0000000000000000 : kernel32!CreateFileWImplementation+0x7d
0000000002b0df00 000007fefe43832e : 0000000000000000 000007feff085027 000007fefe701610 000007fefe2fc4cc : SHELL32!CFSTransfer::_OpenSrcFileWithRetry+0x222
0000000002b0e010 000007fefe436cee : 000007fefe6dc300 0000000000020206 0000000000000000 000000000889d230 : SHELL32!CFSTransfer::OpenItem+0xf1
0000000002b0e0d0 000007fefe2fda9e : 0000000000000000 00000000086e3850 000000008027003f 000000000890b080 : SHELL32!CCopyOperation::Do+0x1de
0000000002b0ea50 000007fefe2fe3b5 : 00000000086e3850 00000000086e3850 00000000086e3850 000000000889d220 : SHELL32!CCopyWorkItem::_DoOperation+0x42
0000000002b0eac0 000007fefe2fee72 : 000000000890b080 000000000890b080 000000000890b080 000000000890b080 : SHELL32!CCopyWorkItem::_SetupAndPerformOp+0x317
0000000002b0eda0 000007fefe2fec0f : 0000000008887a70 0000000000000000 0000000008887a70 0000000008887a70 : SHELL32!CCopyWorkItem::ProcessWorkItem+0x28e
0000000002b0f0d0 000007fefe2fddd6 : 0000000006b4b8b8 0000000006b4b8b8 0000000000000000 0000000000000000 : SHELL32!CRecursiveFolderOperation::Do+0x30c
0000000002b0f170 000007fefe2ff61f : fffffffffffffffe 0000000000000001 00000000087b9630 00000000088c69d0 : SHELL32!CFileOperation::_EnumRootDo+0x24d
0000000002b0f230 000007fefe50f508 : 0000000000000000 0000000000000000 0000000000000001 00000000088c69e0 : SHELL32!CFileOperation::PrepareAndDoOperations+0x320
0000000002b0f320 000007fefe4d3957 : 0000000000000002 0000000000000000 0000000000000000 00000000088ed9a8 : SHELL32!CFileOperation::PerformOperations+0x1e0
0000000002b0f380 000007fefe606e3f : 0000000000000000 0000000006b65ca0 0000000006b65ca0 0000000006b65ca0 : SHELL32!SHFileOperationEx+0x137
0000000002b0f400 000007fefe606b76 : 0000000006b65ca0 0000000006b65ca0 0000000000000002 0000000006b65ca0 : SHELL32!CFSDropTargetHelper::_MoveCopyHIDA+0x157
0000000002b0f4a0 000007fefe606ccd : 0000000006b65ca0 0000000006b65ca0 0000000000000000 0000000000000000 : SHELL32!CFSDropTargetHelper::_Drop+0x316
0000000002b0f770 000007feff07c8ea : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHELL32!CFSDropTargetHelper::s_DoDropThreadProc+0x75
0000000002b0f7a0 000000007709f56d : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : SHLWAPI!WrapperThreadProc+0x19b
0000000002b0f8a0 00000000771d2ca1 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : kernel32!BaseThreadInitThunk+0xd
0000000002b0f8d0 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : ntdll!RtlUserThreadStart+0x1d

0: kd> !irp fffffa8004129010
Irp is active with 13 stacks 13 is current (= 0xfffffa8004129440)
No Mdl: No System Buffer: Thread fffffa80039bc540: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 fffffa80042ec490 00000000 fffff88001144980-fffffa8004129c30
\FileSystem\fastfat fltmgr!FltpSynchronizedOperationCompletion
Args: 00000000 00000000 00000000 00000000

[0, 0] 0 0 fffffa80042d9950 fffffa80046c9c40 00000000-00000000
\FileSystem\FltMgr
Args: fffff88006212870 01000064 00010000 00000000
0: kd> !fileobj fffffa80046c9c40

\eicar.com

Device Object: 0xfffffa80038d7bd0 \Driver\volmgr
Vpb: 0xfffffa8002f58150
Access: Read SharedRead

Flags: 0x284062
Synchronous IO
Sequential Only
Cache Supported
Cleanup Complete
Fast IO Read
Open Cancelled

FsContext: 0xfffff8a001854410 FsContext2: 0xfffff8a0019cbac0
CurrentByteOffset: 0
Cache Data:
Section Object Pointers: fffffa80045b1a90
Shared Cache Map: 00000000

Any clues as to what might be going wrong here?

Thanks.
-Prasad

2

Hi Prasad

Might help if you can find the IRP_MJ_SET_FILE_INFORMATION IRP that is processing the delete.

Try !irpfind 0 0 FileObject fffffa80046c9c40

Regards

Mark

3

Hi Mark,

I tried but could not find the IRP_MJ_SET_FILE_INFORMATION IRP. The command only returned me the original create IRP.

0: kd> !irpfind 0 0 FileObject fffffa80046c9c40
Looking for IRPs with file object == fffffa80046c9c40

Scanning large pool allocation table for Tag: Irp? (fffffa800302c000 : fffffa80030ec000)

Searching NonPaged pool (fffffa8001804000 : ffffffe000000000) for Tag: Irp?

Irp [Thread] irpStack: (Mj,Mn) DevObj [Driver] MDL Process
fffffa8004129010 [fffffa80039bc540] irpStack: ( 0, 0) fffffa80042d9950 [\FileSystem\FltMgr]

Thanks.
-Prasad

4

I have a filter that does what you describe and it never hangs so I suspect
there is an implementation error somewhere.

So sorry to ask the obvious, in you preoperation callback, did you return
FLT_PREOP_SYNCHRONIZE ? (You can’t get away with
FLT_PREOP_SUCCESS_WITH_CALLBACK). In your post operation callback did you
check if the operation succeeded ?

//Daniel

5

Hi Daniel,

Yes, I did

As I said, this works fine otherwise. It hangs only when the infected file is detected on a readonly USB memory and I attempt to do remediation by deleting the file.

Thanks.
-Prasad

6

The IRP should be there on stack check arguments for
FsRtlCancellableWaitForSingleObject and probe a bit mostly in few
tries you will get the right IRP.

I dont have the answers to your query but at the risk of asking the
obvious, why cant you skip the operation for a read only media
ultimately the operation is going to fail? Also what Filesystem is
there on USB drive?