Microsoft has detailed its next step to eliminate uninitialized memory problems, this time targeting uninitialized kernel pool memory used by developers creating hardware drivers for Windows.
These uninitialized memory vulnerabilities account for up to one in 10 of all Microsoft CVEs in recent years, according to Joe Bialek, a security engineer at the Microsoft Security Response Center (MSRC).
“The uninitialized kernel pool vulnerabilities account for just under half of all the uninitialized memory issues reported to Microsoft between 2017 and mid-2018,” says Bialek.
Last month, Bialek detailed Microsoft’s InitAll project to address uninitialized memory vulnerabilities. InitAll was enabled in kernel mode code, Hyper-V code, and network-related user mode services in Windows 10 version 1903 and later.
It’s part of Microsoft’s biggest effort to eliminate memory-related bugs, which have made up about 70% of all patches Microsoft shipped in the past decade, in part because Windows was written in C and C ++. It is also why Microsoft is exploring Rust to rewrite some Windows components.
Microsoft’s goal is to know that your code has no uninitialized kernel group built-in problems and to implement a solution that has minimal performance impact.
Their answer is called ‘group zeroing’, introduced through the new Windows Kernel Pool application programming interfaces (APIs) in Windows 10 version 2004, which are designed to cause minimal fuss for driver developers and Windows applications.
“We remain hopeful that these mitigations primarily remove the threat of a vulnerability class that accounted for 5-10% of all Microsoft CVEs in recent years,” says Bialek.
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 make driver developers more explicit about what they are doing in their program. There will never be any question whether a developer actually intended for a mapping not to be initialized or reset to zero as the behavior is explicitly specified. in the name of the API, “explains Bialek.
Bialek notes that the new group zeroing APIs require code changes for their use. To support these APIs, Microsoft has revised the Windows memory manager and made changes to future versions of Hyper-V and network components.
“Our current plan is to convert all the code in kernel mode to the new APIs in the near future using automated error-filing tools to help ensure that everything is converted,” he says.
Microsoft is exploring how it can help third-party driver manufacturers get out of the old group APIs.
Bialek is confident that the new group APIs should largely eliminate uninitialized memory vulnerabilities in Windows.
“Once we finish transitioning our code to the new group APIs, most of the uninitialized memory vulnerabilities that currently affect customers will be mitigated in Windows,” he says.
“Uninitialized memory vulnerabilities will still be possible, of course, but between InitAll that protects the stack and most allocations using the zeroing indicator, the chances of these issues creeping in will be much lower.”
