New issue
Advanced search Search tips
Starred by 4 users
Status: Fixed
Owner:
Closed: Aug 9
Cc:



Sign in to add a comment
Windows Kernel pool memory disclosure in nt!NtNotifyChangeDirectoryFile
Project Member Reported by mjurczyk@google.com, Mar 8 2017 Back to list
We have discovered that the nt!NtNotifyChangeDirectoryFile system call discloses portions of uninitialized pool memory to user-mode clients, due to output structure alignment holes.

On our test Windows 10 32-bit workstation, an example layout of the output buffer is as follows:

--- 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:

--- cut ---
00000000: 10 00 00 00 04 00 00 00 02 00 00 00 62 00[91 91]............b...
00000010: 00 00 00 00 05 00 00 00 02 00 00 00 63 00 ?? ?? ............c...
--- cut ---
00000000: 10 00 00 00 04 00 00 00 02 00 00 00 62 00[3d 3d]............b.==
00000010: 00 00 00 00 05 00 00 00 02 00 00 00 63 00 ?? ?? ............c...
--- cut ---

Repeatedly triggering the vulnerability could allow local authenticated attackers to defeat certain exploit mitigations (kernel ASLR) or read other secrets stored in the kernel address space.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse or a patch has been made broadly available, the bug report will become visible to the public.

References:
[1] FILE_NOTIFY_INFORMATION structure, https://msdn.microsoft.com/pl-pl/library/windows/desktop/aa364391(v=vs.85).aspx
 
ReadDirectoryChanges.cpp
2.4 KB View Download
Project Member Comment 1 by mjurczyk@google.com, Mar 8 2017
Labels: Reported-2017-Mar-8
Project Member Comment 2 by mjurczyk@google.com, Mar 9 2017
Labels: MSRC-37700
Project Member Comment 3 by mjurczyk@google.com, May 20 2017
Labels: CVE-2017-0299
Project Member Comment 4 by mjurczyk@google.com, Jun 1
Labels: Deadline-Exceeded Deadline-Grace
MSRC have requested the grace period extension aiming to fix on June 2017 Patch Tuesday.
Project Member Comment 5 by mjurczyk@google.com, Jun 13
Labels: Fixed-2017-Jun-13
Status: Fixed
Fixed in today's Patch Tuesday.
Project Member Comment 6 by mjurczyk@google.com, Jun 20
Labels: -restrict-view-commit
Project Member Comment 7 by mjurczyk@google.com, Jun 22
Labels: -Fixed-2017-Jun-13
Status: New
Changing back to New as the issue still appears to reproduce on up-to-date Windows 7 and 10 (32-bit).
Project Member Comment 8 by mjurczyk@google.com, Jun 27
Labels: -Deadline-Grace
MSRC has indeed confirmed that the fix released on June Patch Tuesday is incorrect and doesn't resolve the bug properly. As such, the vulnerability still reproduces on Windows 7-10 with the original proof-of-concept program. A revised fix is expected to be shipped in the July (7/11) or August (8/8) Patch Tuesday at the latest.
Project Member Comment 9 by mjurczyk@google.com, Aug 9
Labels: Fixed-2017-Aug-8
Status: Fixed
The bug has now been properly fixed in the August Patch Tuesday. See the bulletin's revision history at https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-0299.
Sign in to add a comment