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
Posts
The Wannacry and NotPetya bug - CVE-2017-0144 SMB Remote Execution RCE
- Get link
- X
- Other Apps
I've seen a lot of descriptions of the bug that Wannacry and now NotPetya leveraged to worm its way into the spotlight, but most of them are pretty vague. Descriptions range from "logic error" and "buffer overflow" to Trend Micro's post that actually called out the actual bug - a casting error. But even the Trend Micro post, which went into pretty good detail, didn't show the actual code that the error resided in, only a high level disassembly. There also seems to be some disagreement on where the bug resides in Windows 10. One of the first people to analyze the Wannacry bug and do a write up on it posted his analysis to Reddit and was excoriated in the comments over it because of an error in where he thought the bug was in Windows 10. Long story short, someone insisted very strongly to him that his analysis was wrong, and he eventually took down the analysis entirely changed the URL of the analysis and posted an errata regarding the location of t
Analysis of Windows kernel information disclosure from CVE-2017-0167
- Get link
- X
- Other Apps
In CVE-2017-0167 Google Security found a Windows kernel information disclosure through the user mode callback user32! fnINLPUAHDRAWMENUITEM . A sub-function of CreateWindow issues a syscall that in return calls a user mode callback with a copy of a data structure from kernel space. This data structure is copied from the stack while executing in the kernel, and a portion of that structure is uninitialised, meaning that it can contain stale stack data that can be used to glean information from the kernel in order to defeat protections like KASLR. Google Security included a brief write up of the bug and even supplied a PoC to demonstrate it, but didn't go into detail about how the bug actually works. Given that the bug is actually pretty straightforward I think it's worth going into a little bit deeper and getting a better idea of what's going on under the hood and how an oversight as simple as not initialising a structure lead to a kernel to userspace information disclo