Message 7 of 7
17 Dec 12 17:49
Join Date: 24 Jul 2008
Posts To This List: 1016
DEP/ASLR in a kernel driver
The kernel has provided ASLR for kernel mode modules since Vista SP1/WS08. The
statements earlier in the thread aren't fully correct for these and newer
Windows versions. There is no need to opt in to kernel ASLR with the dynamicbase
flag for kernel mode modules; it is automatically applied on supported kernels.
Prior to Vista SP1, drivers had no preferred base address but would tend to load
at the same base address for a given static mix of drivers on a particular
NX is also enforced for drivers. There is no need to set the nxcompat flag for
kernel mode modules to opt in to this. If an allocation is not protected as
executable in kernel mode, then it cannot be executed from unless the user
completely disabled NX for the whole system with /noexecute=disable in the OS
On Win8 and above, you can request non executable pool allocations from
NonPagedPool using the new NonPagedPoolNx pool type
has details. There is a mechanism to request NX NP pool on Win8, while
automatically falling back to executable NP pool on earlier OS versions within
the same driver binary; see the MSDN link for details. Drivers built for
architectures other than x86/amd64/ia64 (i.e., ARM) default to using
NonPagedPoolNx for the NonPagedPool constant unless the NonPagedPoolExecute
constant is used in source text.
Converting to NX pool is worth doing; your customers would much rather have a
vulnerability exist and not be exploited than to be compromised from said issue,
and NX pool raises the difficulty in writing working kernel exploit code.
- S (Msft)
From: Tim Roberts
Sent: ?12/?17/?2012 9:58
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DEP/ASLR in a kernel driver
Puchu Pachok wrote:
> I don't think I get the comment " /aslr doesn't exist in km". Don't
> the virtual addresses where the kernel and drivers are loaded change
> for each boot sessions (much the same way the memory location of
> ntdll, kernel32, etc. change on each boot)? If so, doesn't it mean
> address space randomization is indeed happening?
If your driver set doesn't change, then all kernel drivers in your next
boot will have the same addresses they had in this boot. The boot
process is deterministic. Kernel32.dll is a user-mode DLL, where ASLR
makes the module address assignments non-deterministic.
Tim Roberts, email@example.com
Providenza & Boekelheide, Inc.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at