System service hooking (and kernel mode hooking in general) is one of those near-and-dear things to me which I’ve got mixed feelings about. (System service hooking refers to intercepting system calls, like NtCreateFile, in kernel mode using a custom driver.)
On one hand, hooking things like system services can be extremely tricky at best, and outright dangerous at worst. There are a number of ways to write code that is almost right, but will fail in rare edge cases. Furthermore, there are even more ways to write code that will behave correctly as long as system service callers “play nicely” and do the right thing, but sneaks in security holes that only become visible once somebody in user mode tries to “bend the rules” a bit.
On the other hand, though, there are certainly some interesting things that one can do in kernel mode, for which there really aren’t any supported or well-defined extensibility interfaces without “getting one’s hands dirty” with a little hooking, here or there.
Microsoft’s policy on hooking in kernel mode (whether patching system services or otherwise) is pretty clear: They would very much rather that nobody even thought about doing anything remotely like code patching or hooking. Having seen virtually every anti-virus product under the sun employ hooking in one way or another at some point during their lifetime (and subsequently fail to do it correctly, usually with catastrophic consequences), I can certainly understand where they are coming from. Then again, I have also been on the other side of the fence once or twice, having been blocked from implementing a particular useful new capability due to a certain anti-patching system on recent Windows versions that shall remain nameless, at least for this posting.
Additionally, in further defense of Microsoft’s position, the vast majority of code I have seen in the field that has performed some sort of kernel mode hooking has done some out of a lack of understanding of the available and supported kernel mode extensibility interfaces. There are, furthermore, a number of things where hooking system services won’t even get the desired result (even if it weren’t otherwise fraught with problems); for instance, attempting to catch file I/O by hooking NtReadFile/NtReadFileScatter/NtWriteFile/NtWriteFileGather will cause one to completely miss any I/O that is performed using a mapped section view.
Nonetheless, system service hooking seems to be an ever-increasing trend, one that doesn’t seem to be likely to go away any time soon (at least for 32-bit Windows). There are also, of course, bits of malicious code out there which attempt to do system service hooking as well, though in my experience, once again, the worst (and most common) offenders have been off-the-shelf software that was likely written by someone who didn’t really understand the consequences of what they were doing.
Rather than weigh in on the side of “Microsoft should allow all kernel mode hooking”, or “All code hooking is bad”, however, I thought that a different viewpoint might be worth considering on this subject. At the risk of incurring Don Burn’s wrath by even mentioning the subject (an occurrence that is quite common on the NTDEV list (if one happens to follow that), I figured that it might be instructive to provide an example of just how easy it is to slip up in a seemingly innocent way while writing a system service hook. Of course, “innocent slip-ups” in kernel mode often equate to bugchecks at their best, or security holes at their worst.
Thus, the following, an example of how a perfectly honest attempt at hooking a system service can go horribly wrong. This is not intended to be a tutorial in how to hook system services, but rather an illustration of how one can easily create all sorts of nasty bugs even while trying to be careful.
The following code assumes that the system service in question (NtCreateSection) has had a hook “safely” installed (BuggyDriverHookNtCreateSection). This posting doesn’t even touch on the many and varied problems of safely trying to hook (or even worse, unhook) a system service, which are also typically done wrong in my experience. Even discounting the diciness of those problems, there’s plenty that can go wrong here.
I’ll post a discussion of some of the worst bugs in this code later on, after people have had a chance to mull it over for a little while. This routine is a fairly standard attempt to post-process a system service by doing some additional work after it completes. Feel free to post a comment if you think you have found one of the problems (there are several). Bonus points if you can identify why something is broken and not just that it is broken (e.g. provide a scenario where the existing code breaks). Even more bonus points if you can explain how to fix the problem you have found without introducing yet another problem or otherwise making things worse – by asking that, I am more wanting to show that there are a great deal of subleties at play here, instead of simply showing how to operate an NtCreateSection hook correctly. Oh, and there’s certainly more than one bug here to be found, as well.
N.B. I haven’t run any of this through a compiler, so excuse any syntax errors that I missed.
Without further adeu, here’s the code:
//
// Note: This code has bugs. Please don't actually try this at home!
//
NTSTATUS
NTAPI
BuggyDriverNtCreateSection(
OUT PHANDLE SectionHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN PLARGE_INTEGER SectionSize OPTIONAL,
IN ULONG Protect,
IN ULONG Attributes,
IN HANDLE FileHandle
)
{
NTSTATUS Status;
HANDLE Section;
SECTION_IMAGE_INFORMATION ImageInfo;
ULONG ReturnLength;
PVOID SectionObject;
PVOID FileObject;
BOOLEAN SavedSectionObject;
HANDLE SectionKernelHandle;
LARGE_INTEGER LocalSectionSize;
SavedSectionObject = FALSE;
//
// Let's call the original NtCreateSection, as we only care about successful
// calls with valid parameters.
//
Status = RealNtCreateSection(
SectionHandle,
DesiredAccess,
ObjectAttributes,
SectionSize,
Protect,
Attributes,
FileHandle
);
//
// Failed? We'll bail out now.
//
if (!NT_SUCCESS( Status ))
return Status;
//
// Okay, we've got a successful call made, let's do our work.
// First, capture the returned section handle. Note that we do not need to
// do a probe as that was already done by NtCreateSection, but we still do
// need to use SEH.
//
__try
{
Section = *SectionHandle;
}
__except( EXCEPTION_EXECUTE_HANDLER )
{
Status = (NTSTATUS)GetExceptionCode();
}
//
// The user unmapped our buffer, let's bail out.
//
if (!NT_SUCCESS( Status ))
return Status;
//
// We need a pointer to the section object for our work. Let's grab it now.
//
Status = ObReferenceObjectByHandle(
Section,
0,
NULL,
KernelMode,
&SectionObject,
NULL
);
if (!NT_SUCCESS( Status ))
return Status;
//
// Just for fun, let's check if the section was an image section, and if so,
// we'll do special work there.
//
Status = ZwQuerySection(
Section,
SectionImageInformation,
&ImageInfo,
sizeof( SECTION_IMAGE_INFORMATION ),
&ReturnLength
);
//
// If we are an image section, then let's save away a pointer to to the
// section object for our own use later.
//
if (NT_SUCCESS(Status))
{
//
// Save pointer away for something that we might do with it later. We might
// want to care about the section image information for some unspecified
// reason, so we will copy that and save it in our tracking list. For
// example, maybe we want to map a view of the section into the initial
// system process from a worker thread.
//
Status = SaveImageSectionObjectInList(
SectionObject,
&ImageInfo
);
if (!NT_SUCCESS( Status ))
{
ObDereferenceObject( SectionObject );
return Status;
}
SavedSectionObject = TRUE;
}
//
// Let's also grab a kernel handle for the file object so that we can do some
// sort of work with it later on.
//
Status = ObReferenceObjectByHandle(
Section,
0,
NULL,
KernelMode,
&FileObject,
NULL
);
if (!NT_SUCCESS( Status ))
{
if (SavedSectionObject)
DeleteImageSectionObjectInList( SectionObject );
ObDereferenceObject( SectionObject );
return Status;
}
//
// Save the file object away, as well as maximum size of the section object.
// We need the size of the section object for a length check when accessing
// the section later.
//
if (SectionSize)
{
__try
{
LocalSectionSize = *SectionSize;
}
__except( EXCEPTION_EXECUTE_HANDLER )
{
Status = (NTSTATUS)GetExceptionCode();
ObDereferenceObject( FileObject );
if (SavedSectionObject)
DeleteImageSectionObjectInList( SectionObject );
ObDereferenceObject( SectionObject );
return Status;
}
}
else
{
//
// Ask the file object for it's length, this could be done by any of the
// usual means to do that.
//
Status = QueryAllocationLengthFromFileObject(
FileObject,
&LocalSectionSize
);
if (!NT_SUCCESS( Status ))
{
ObDereferenceObject( FileObject );
if (SavedSectionObject)
DeleteImageSectionObjectInList( SectionObject );
ObDereferenceObject( SectionObject );
return Status;
}
}
//
// Save the file object + section object + section length away for future
// reference.
//
Status = SaveSectionFileInfoInList(
FileObject,
SectionObject,
&LocalSectionSize
);
if (!NT_SUCCESS( Status ))
{
ObDereferenceObject( FileObject );
if (SavedSectionObject)
DeleteImageSectionObjectInList( SectionObject );
ObDereferenceObject( SectionObject );
return Status;
}
//
// All done. Lose our references now. Assume that the Save*InList routines
// took their own references on the objects in question. Return to the caller
// successfully.
//
ObDereferenceObject( FileObject );
ObDereferenceObject( SectionObject );
return STATUS_SUCCESS;
}