Another day, another Windows kernel information disclosure discovered by Project Zero :)
In CVE-2017-8564 Google Security discloses yet another Windows kernel information disclosure bug that can be triggered through an undocumented WinAPI function. They've really been grinding away at these lately, it seems like you can't even turn around without a new information disclosure bug being published.
This time, the bug has to do with an IOCTL handled by nsiproxy.sys (which eventually calls into netio.sys) originally dispatched by NsiGetParameter from Nsi.dll. NsiGetParameter is an undocumented WinAPI call and isn't included in any of the Windows SDK Header files, but instead has to be resolved through a GetProcAddress call on Nsi.dll.
After all the checking and sanitizing that happens to any user to kernel mode call in the Windows environment, our little ioctl eventually makes its way to NsiGetparameterEx in netio.sys. This is where our bug is. Diffing the pre and post patch version shows a few differences, but the function is really frickin big...
Skimming through the differences shows that they're mostly superficial. But near the bottom of the function, we see a real difference. Look at this bit of code here -
We see a block of memory is allocated and a pointer to it is stuffed into ebx. No big deal. But look at what is done with this block of memory...
The pre-patch version has red highlights, the post-patch version has green highlights.
A memset call was added! This HAS to be where the bug was! Bug what's going on? A block of memory is allocated, and in the pre-patch version an offset in that block of memory is used as the src argument for memcpy and then the block is freed. In the post patch version, the block is memcpy'd bfeore being the src argument for a memcpy call. In the pre-patch function, the dst arg, the offset into the block used as src, and the size are all derived from esi, which is arg2. I don't know what the arguments represent but it ultimately doesn't matter - we're memcpying out of a seemingly uninitialized just-allocated buffer in the kernel and then passing that back to user mode.
These kernel heap information disclosures might seem like small potatoes but they represent something bigger - an expression of the Windows kernel and an audit of undocument functions that probably should have happened long ago.
In CVE-2017-8564 Google Security discloses yet another Windows kernel information disclosure bug that can be triggered through an undocumented WinAPI function. They've really been grinding away at these lately, it seems like you can't even turn around without a new information disclosure bug being published.
This time, the bug has to do with an IOCTL handled by nsiproxy.sys (which eventually calls into netio.sys) originally dispatched by NsiGetParameter from Nsi.dll. NsiGetParameter is an undocumented WinAPI call and isn't included in any of the Windows SDK Header files, but instead has to be resolved through a GetProcAddress call on Nsi.dll.
After all the checking and sanitizing that happens to any user to kernel mode call in the Windows environment, our little ioctl eventually makes its way to NsiGetparameterEx in netio.sys. This is where our bug is. Diffing the pre and post patch version shows a few differences, but the function is really frickin big...
Skimming through the differences shows that they're mostly superficial. But near the bottom of the function, we see a real difference. Look at this bit of code here -
We see a block of memory is allocated and a pointer to it is stuffed into ebx. No big deal. But look at what is done with this block of memory...
The pre-patch version has red highlights, the post-patch version has green highlights.
A memset call was added! This HAS to be where the bug was! Bug what's going on? A block of memory is allocated, and in the pre-patch version an offset in that block of memory is used as the src argument for memcpy and then the block is freed. In the post patch version, the block is memcpy'd bfeore being the src argument for a memcpy call. In the pre-patch function, the dst arg, the offset into the block used as src, and the size are all derived from esi, which is arg2. I don't know what the arguments represent but it ultimately doesn't matter - we're memcpying out of a seemingly uninitialized just-allocated buffer in the kernel and then passing that back to user mode.
These kernel heap information disclosures might seem like small potatoes but they represent something bigger - an expression of the Windows kernel and an audit of undocument functions that probably should have happened long ago.
Comments
Post a Comment