Kernel-Mode Mistakes

Kernel-Mode Mistakes

Some errors in kernel-mode code, such as that for device drivers, can have catastrophic denial of service results. This section outlines some of the simple mistakes made and how they can be countered.

Using User-Mode Memory

A widespread mistake is not performing correct validation of pointers provided to kernel mode from user mode and assuming that the memory location is fixed. The mapping between kernel-mode memory and user-mode memory is dynamic and can change asynchronously. Not only that, but other threads and multiple CPUs can change the protection on memory pages without notifying your thread. It s also possible that an attacker will attempt to pass a kernel-mode address rather than a user-mode address to your driver, causing instability in the system as code blindly writes to kernel memory.

You can mitigate most of these issues by probing all user-mode addresses inside a try/except block prior to using functions such as MmProbeAndLockPages and ProbeForRead and then wrapping all user-mode access in try/except blocks. The following sample code shows how to achieve this:

STATUS AddItem(PWSTR ItemName, ULONG Length, ITEM *pItem) { STATUS status = ERR_NO_ITEM; try { ITEM *pNewItem = GetNextItem(); if (pNewItem) { // ProbeXXXX raises an exception on failure. // Align on LARGE_INTEGER boundary. ProbeForWrite(pItem, sizeof ITEM, TYPE_ALIGNMENT(LARGE_INTEGER)); CopyMemory(pItem, pNewItem, sizeof ITEM); status = NO_ERROR; } } except (EXCEPTION_EXECUTE_HANDLER) { status = GetExceptionCode(); } return status; }

Accessing Privileged Interfaces Through Unprotected IOCTLs

If your kernel-mode code has protected interfaces, make sure that all entry points, including input/output controls (IOCTLs), perform access checks, not just the exported function calls.