Microsoft has detailed its next step in eliminating uninitialized memory issues, this time targeting the uninitialized kernel pool memory used by developers who build hardware drivers for Windows.
These uninitialized memory vulnerabilities represent as many as one in 10 of all Microsoft CVEs in recent years, according to Joe Bialek, a security engineer in the Microsoft Security Response Center (MSRC).
“Uninitialized kernel pool vulnerabilities account for a little under half of all uninitialized memory issues that were reported to Microsoft between 2017 and the middle of 2018,” notes Bialek.
Bialek last month detailed Microsoft’s InitAll project to address uninitialized memory vulnerabilities. InitAll was enabled in kernel-mode code, Hyper-V code, and networking-related user-mode services from Windows 10 version 1903 and newer.
It’s part of Microsoft’s larger effort to kill off memory-related bugs, which have made up about 70% of all patches Microsoft shipped over the past decade, in part because of Windows being written in C and C++. It’s also why Microsoft is exploring Rust to rewrite some Windows components.
Microsoft’s goal is to know that its code doesn’t have built-in uninitialized kernel pool issues and to implement a solution that has minimal impact on performance.
Its answer is called ‘pool zeroing’, introduced via new Windows Kernel Pool application programming interfaces (APIs) in Windows 10 version 2004, which are designed to cause minimal fuss for Windows application and driver developers.
“We remain hopeful that these mitigations will mostly eliminate the threat of a vulnerability class that accounted for 5% to 10% of all Microsoft CVEs in recent years,” Bialek says.
The APIs are called ExAllocatePool2 and ExAllocatePool3. There are also separate tools available to support versions of Windows 10 prior to 2004.
“The intention here is to get driver developers a way to be more explicit about what they are doing in their program. There will never be any question of if a developer truly intended for an allocation to be uninitialized or zeroed since the behavior is explicitly specified in the API name,” explains Bialek.
Bialek notes that the new pool-zeroing API’s require code changes to use. To support these APIs, Microsoft has overhauled the Windows memory manager and made changes to future releases of Hyper-V and networking components.
“Our current plan is to convert all kernel-mode code over to the new API’s in the near future using automatic bug-filing tools to help ensure everything gets converted,” he says.
Microsoft is exploring how it can help makers of third-party drivers to move off old pool APIs.
Bialek is confident that the new pool APIs should for the most part eliminate uninitialized memory vulnerabilities in Windows.
“Once we finish transitioning our code over to the new pool API’s, the majority of uninitialized memory vulnerabilities that currently affect customers will be mitigated on Windows,” he says.
“Uninitialized memory vulnerabilities will still be possible of course, but between InitAll protecting the stack and most allocations using the zeroing flag, the chances of these issues sneaking in will be much smaller.”
