Google 0Day项目发现了微软Windows操作系统中的另一个安全漏洞，但这次所有细节都已发布在网上，因为微软在90天的披露截止日期之前，未能解决这个问题。

根据“0Day项目指南”，供应商有90天时间来修复作为程序的一部分报告的漏洞，否则所有细节将在网上公布。

2017年3月，Google工程师们首次在Windows内核中发现了漏洞，该团队甚至同意为微软将标准期限延长至90天，为了给公司更多的时间来创建补丁。微软的确在2017年6月补丁包中包含了相关补丁，并交付给所有用户，但即使在打了补丁系统上，它看起来仍然存在漏洞。

所有Windows版本现在都很脆弱

Google表示，该漏洞允许任何人访问内核内存，并最终绕过Windows 10中的安全措施。该漏洞被标记为中等严重风险。[出自:jiwo.org]
据Neowin网站，在所有的Windows版本均存在这个漏洞，包括Windows 7到Windows 10及中间的所有版本，但似乎只有32位Windows版本受到影响。

最糟糕的是，虽然所有细节都已经在网上公开了，微软似乎并没有急于提供一个解决方案，该公司只想发布一个新补丁，它会在7月11日或8月的补丁包中处理这个漏洞。Google在其报告中表示

“MSRC已经证实，在六月发布的星期二补丁是不正确，无法正确的解决bug。因此，该漏洞仍然存在于Windows 7至Windows 10上所有版本中，PoC已经公开。修订版预计将于七月（7/11）或8月（8/8）的星期二发布

Windows 内核内存访问漏洞

该漏洞允许任何人访问内核内存。Windows中的 nt!NtNotifyChangeDirectoryFile 系统调用，据说允许用户模式查看，并能够访问未初始化的池内存。Google表示:

--- cut ---

00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................

00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?? ?? ................

--- cut ---

Where 00 denote bytes which are properly initialized, while ff indicate uninitialized values copied back to user-mode. The output data is returned in a list of FILE_NOTIFY_INFORMATION structures [1]. If we map the above shadow bytes to the structure definition, it turns out that the uninitialized bytes correspond to the alignment hole between the end of the FileName string and the beginning of the adjacent FILE_NOTIFY_INFORMATION structure, if that string is of an odd length (and therefore not 4-byte aligned).

The issue can be reproduced by running the attached proof-of-concept program on a system with the Special Pools mechanism enabled for ntoskrnl.exe. Then, it is clearly visible that bytes at the aforementioned offsets are equal to the markers inserted by Special Pools, and would otherwise contain leftover data that was previously stored in that memory region [...]

Google声称，多次触发该漏洞，允许经过本地认证的攻击者实施“defeat certain exploit mitigations （内核ASLR）”，读取内核地址空间的其他部分。

详细的技术分析在这里

https://bugs.chromium.org/p/project-zero/issues/detail?id=1169&q=