tl;dr
The Windows V2004 WDK/EWDK had a serious security vulnerability. It has been updated to mitigate that vulnerability, and you should update all of your machines that have the WDK/EWDK installed. However, updating the WDK/EWDK might not be enough in all circumstances. There are driver code-level mitigations that you should implement to ensure security regardless of the WDK version you build with, and to be consistent with best practices.
Background
Back in July, we discovered a security vulnerability in Windows 1909 and the Windows 2004 WDK, regarding a group of new security-oriented functions related to ExAllocatePoolZero. We immediately reported this issue to Microsoft, who posted a notice in the WDK forum and on the relevant doc pages. To avoid repeating everything we know about this vulnerability, please see our original blog post on this topic.
Microsoft Provides Mitigations
On 16 December 2020, Microsoft issued a “security refresh” of the Windows 2004 WDK. This updated both the standard Visual Studio WDK and the Enterprise WDK. These new versions have now replaced the original versions of the Windows 2004 WDK that are available for download from the WDK download page.
To determine which version of the WDK you have installed, look in the “Add or Remove Programs” dialog. The original (not security mitigated) WDK has the version 10.0.19041.0 or 10.0.19041.1 — The new (security mitigated) WDK shows up as version 10.0.19041.685.
In addition to issuing the WDK updates, Microsoft has issued a security update for Windows 1909 that fixes this vulnerability. It is not known which, specific, update includes this fix.
Best Practices — What You Need to Do. Now.
First, it’s important that you update to using the new, security mitigated, versions of the Windows 2004 WDK and EWDK as soon as possible. The changes that are made in this update are very focused and limited, but they are extremely important. In our testing here at OSR, we did not encounter any incompatibilities between the original WDK versions and the updated versions. We therefore strongly recommend that all new driver releases be built with the updated versions.
However, while building with the latest WDK is effective in mitigating the problem, this by itself is not sufficient and falls short of best practices unless you can be 100% sure that every build of your driver will always be built with nothing older than the updated WDK. Most development organizations are distributed, and use many different methods to build their drivers — even those for release to customers. It can, therefore, be exceptionally difficult to guarantee with any certainty that every single version of the WDK/EWDK on every build machine everywhere has been updated. Further, it may be inconvenient or impractical to immediately update some build environments.
To be sure that your driver always does the right thing, we strongly recommend that you follow the same practice that we use here at OSR, which we describe in the box below labeled “OSR’s ExAllocatePoolZero Mitigation” — You can see also an example of the code we use below.
VOID OsrFixExPoolZeroingNativelySupported() { #ifndef POOL_ZEROING_INFORMATION RTL_OSVERSIONINFOW versionInfo; if (ExPoolZeroingNativelySupported) { // // Rather than testing for 1909 // test against not being 2004 (19041) // RtlZeroMemory(&versionInfo, sizeof(RTL_OSVERSIONINFOW)); versionInfo.dwOSVersionInfoSize = sizeof(versionInfo); if (!NT_SUCCESS(RtlGetVersion(&versionInfo))) { ExPoolZeroingNativelySupported = FALSE; } else if ((versionInfo.dwMajorVersion == 10) && (versionInfo.dwMinorVersion == 0) && (versionInfo.dwBuildNumber < 19041)) { ExPoolZeroingNativelySupported = FALSE; } } #endif }
[…] Update: Late in December 2020 Microsoft issued an update to the WDK/EWDK that includes mitigations for this security issue. See our blog post describing these updates. […]