At present, a security tool I maintain can block the loading of DLLs into certain vulnerable processes by intercepting them being mapped into memory via a Pre callback on IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION
.
It checks the Iopb->Parameters.AcquireForSectionSynchronization.PageProtection
as a means to tell if they’re DLLs and looks for:
PAGE_EXECUTE | PAGE_EXECUTE_READ | PAGE_EXECUTE_READWRITE | PAGE_EXECUTE_WRITECOPY
Recently, we discovered that this method does not work for .NET DLLs since they’re generally READ_ONLY data rather than executable pages. That’s meant that we need a better way of identifying if the item being mapped into memory is actually a DLL.
The first approach we considered was simply looking at the file extension, but it seems as if that’s prone to identification issues since you can call LoadLibrary() on more or less anything.
The second approach we tried works, and involves examining the PE header on the actual file being mapped by reading from the FILE_OBJECT. We’re worried about the performance implications of this and I was wondering if there was a better approach or if it made more sense to switch our blocking to the Post IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and examine the PE header in memory in the user process after the memory was mapped.
Is there a reason this would be a bad idea? I’m aware we’d need to wrap the examination of the user mode memory in structured exception handling and I’m assuming we can get to the correct memory location by looking at:
pData->Iopb->TargetFileObject->SectionObjectPointer->ImageSectionObject
One of the things that worried me about doing this was that it looked as though I’d have to use the nt!_SEGMENT
structure which looks to be undocumented and may change.
Is there a better approach we could use here? Or one that would allow us to safely examine the in-memory PE header from this filter callback?