what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Windows Kernel Pool Ntfs!LfsRestartLogFile Memory Disclosure

Windows Kernel Pool Ntfs!LfsRestartLogFile Memory Disclosure
Posted Oct 16, 2017
Authored by Google Security Research, mjurczyk

This advisory discusses a Microsoft Windows kernel pool memory disclosure into NTFS metadata ($LogFile) in Ntfs!LfsRestartLogFile.

tags | advisory, kernel
systems | windows
advisories | CVE-2017-11817
SHA-256 | 79957168f93861bbb46f21290a78b65b360080d54ec073682cd4e16fbff74b4b

Windows Kernel Pool Ntfs!LfsRestartLogFile Memory Disclosure

Change Mirror Download
Windows Kernel pool memory disclosure into NTFS metadata ($LogFile) in Ntfs!LfsRestartLogFile 


This tracker entry is a fork of issue #1325, which this bug was reported as a part of. However, as some essential information and context was provided in issue #1325, the "Reported" date was adjusted there to account for it. The new information did not concern the vulnerability discussed here, so we are sticking to the original deadline in this case. Hence the need to create a separate entry in the tracker.

We have discovered that the NTFS.sys driver writes uninitialized kernel pool memory into the internal structures of the file system, while mounting and operating on it. This may be of a security concern in cases where, for example, users share some files with each other via USB sticks or other storage media with NTFS-formatted volumes on them. While the victim would assume that they're only sharing intended data explicitly copied to the disk, they could also unknowingly share bits and pieces of sensitive/confidential information stored in the kernel, that just happened to reside in the memory area used by NTFS.sys while constructing internal file system structures.

Even more scary are leaks which don't require any human interaction and take place immediately when the volume is mounted. In this scenario, it could be possible to disclose kernel memory of a locked machine with physical access to a USB port, by repeatedly plugging in a flash drive (or a device which emulates one), waiting for the uninitialized memory to be written by the system, reading it back and re-mounting the disk.

We have implemented some dedicated logic in our Bochspwn system instrumentation to detect instances of such info leaks. As a result, we have found that pool memory allocated in the Ntfs!LfsRestartLogFile function is leaked to NTFS volumes (both system and external ones). From a security perspective, the leak is quite severe, as it is triggered with no user interaction (just by mounting an NTFS volume), and it discloses ~7.5kB of kernel pool memory in 2 chunks of ~3800 consecutive bytes. This data is saved in the first 8192 bytes of the special $LogFile file, as part of the two "RSTR" restart area records. As we understand it, this means that every NTFS-formatted USB stick last accessed by Windows 7 now includes more than 7kB of junk kernel memory from that computer. However, since $LogFile is an internal file, reading from it requires raw disk access which significantly reduces the impact of the bug.

Interestingly, Windows 8 and 10 are not affected by the flaw, as these newer systems include an extra memset() call immediately following the allocation request:

--- cut ---
PAGE:000D3D2A push 'rsfL' ; Tag
PAGE:000D3D2F imul eax, [edi+18h], 22h
PAGE:000D3D33 shr eax, 1
PAGE:000D3D35 push eax ; NumberOfBytes
PAGE:000D3D36 push 210h ; PoolType
PAGE:000D3D3B mov esi, ds:__imp__ExAllocatePoolWithTag@12 ; ExAllocatePoolWithTag(x,x,x)
PAGE:000D3D41 call esi ; ExAllocatePoolWithTag(x,x,x)
PAGE:000D3D43 mov [edi+198h], eax
PAGE:000D3D49 push dword ptr [edi+18h] ; size_t
PAGE:000D3D4C push ebx ; int
PAGE:000D3D4D push eax ; void *
PAGE:000D3D4E call _memset
--- cut ---

This appears to be an instance of a bug fixed by Microsoft in recent system versions, but not backported to the older, yet still supported ones.

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.

Found by: mjurczyk

Login or Register to add favorites

File Archive:

December 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    11 Files
  • 2
    Dec 2nd
    0 Files
  • 3
    Dec 3rd
    0 Files
  • 4
    Dec 4th
    0 Files
  • 5
    Dec 5th
    0 Files
  • 6
    Dec 6th
    0 Files
  • 7
    Dec 7th
    0 Files
  • 8
    Dec 8th
    0 Files
  • 9
    Dec 9th
    0 Files
  • 10
    Dec 10th
    0 Files
  • 11
    Dec 11th
    0 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By