Is there a way to block the load of .Net dlls via IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION?

BenStaniford

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?

Scott_Noone_(OSR)

Can you capture a ProcMon trace or provide an easy way to reproduce what you're seeing? This is both for my own curiosity and so that I can try to give a complete answer...

Few things:

1. IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION is the notice that the section is being created so you're not guaranteed that it's actually mapped anywhere at that point. The notification of the mapping comes in via PsSetImageLoadNotifyRoutine, but that's informational only (i.e. you can't fail it)
2. Digging into these structures is going to be a recipe for disaster...They're likely to change and there's a lot of locking involved in mucking with them.
3. You can always create your own section with FltCreateSectionForDataScan and use that to get a mapping. I've never tried to call this in the PreAcquireForSectionSynchronization directly, but I've absolutely held up that operation while I mapped the file from another process (e.g. to generate file hashes and whatnot).