Windows: NtCreateTransactionManager Type Confusion Elevation of Privilege

[GoogleCodeExporter]

Windows: NtCreateTransactionManager Type Confusion Elevation of Privilege
Platform: Windows 8.1 Update, Windows 7 (32 and 64 bit)
Class: Elevation of Privilege

Summary:
When creating the log file for a transaction manager the kernel can be made to 
incorrectly handle the returned File object resulting in type confusion leading 
to elevation of privilege. 

Description:

The NtCreateTransactionManger system call (which is actually implemented in 
tm.sys in Windows 8.1) takes a log file parameter to store transactions in. It 
uses the Common Log File System driver (CLFS) to create these logs using the 
ClfsCreateLogFile API. Before passing the log file parameter to that API it 
prepends \??\LOG: to it so that the file is passed to the CLFS driver. Inside 
ClfsCreateLogFile this path is passed to IoCreateFileWithDeviceHint. 

The vulnerability occurs because it’s accessing the driver through the dos 
devices prefix under the current user’s context. Therefore it’s possible 
for a user to place their own symlink into \Sessions\0\DosDevices\X-Y which 
redirects this to another type of device. For example by placing an empty 
symlink you can pass \??\C:\somefile.log to the system call and the CLFS driver 
will actually open up the file directly instead of via CLFS. 

This in itself might not be a serious issue, however when ClfsCreateLogFile 
returns the transaction manager calls the private API 
ClfsPrivGetBaseLogFileFromFileObjectPointer which extracts the underlying file 
object for the file on disk. This API assumes the passed in file object was 
constructed by CLFS which means it just dereferences various structures inside 
the file object to find the underlying log file. This will end up dereferencing 
invalid memory leading to a type confusion. This can lead to memory being 
referenced either at the zero page or some other address in user memory 
depending on what was in memory at the time. Through this an application could 
return an arbitrary file object which can spoof it’s device information 
leading to execution in the kernel. 

I’ve observed a few crashes where it’s not at the zero page so it should be 
exploitable more widely that just Windows 7 32 bit (where the VDM can be used 
to get the zero page mapped). And of course this is a simple test with an NTFS 
file, there are a number of file objects (named pipes, other devices) which 
could be opened which might result in reliable user mode memory pointers being 
made available. I’ve attached a crash report from Windows 7 32 bit showing 
dereference at address 0x006f00ca when retrieving the file object. 

This issue might be resolved (from a symlink perspective) by any fixes applied 
for MSRC-21430 depending on how they’re done. If for example just the order 
of lookup is changed then it looks to be possible to still exploit. This is 
because the TM only adds \??\LOG: to the string and CLFS only checks for the 
same prefix. Therefore you could instead place a symlink for LOG:ABC and pass 
ABC:\??\C:\somefile.log and it would still work. 

The NTFS driver also uses the \??\LOG: prefix when creating its transaction log 
files, therefore that might also have a similar issue, but it hasn’t been 
investigated further. 

Proof of Concept:

I’ve provided a PoC which will cause the crash to occur in the kernel during 
the dereferencing of the file object. The archive password is ‘password’. 
Follow these steps: 

1) Extract the PoC to a location on a local hard disk which is writable by a 
normal user
2) Execute the Poc_TransactionManager_EoP.exe file
3) The OS should crash/blue screen

Expected Result:
The OS shouldn’t crash

Observed Result:
The OS crashes

This bug is subject to a 90 day disclosure deadline. If 90 days elapse without 
a broadly available patch, then the bug report will automatically become 
visible to the public.

Original issue reported on code.google.com by fors...@google.com on 30 Jan 2015 at 6:05

Attachments:

• tm_crash.txt
• Poc_TransactionManager_EoP.7z

[GoogleCodeExporter]

Correspondence Date: 30 Jan 2015

> Microsoft assigned MSRC case 21444 to this issue

Original comment by fors...@google.com on 30 Jan 2015 at 6:22

• Added labels: MSRC-21444

[GoogleCodeExporter]

Confirmed Win10 TP build 9926 is also vulnerable

Original comment by fors...@google.com on 3 Feb 2015 at 9:23

[GoogleCodeExporter]

Some further notes on exploitability. This is theoretically exploitable from a 
heavily restricted sandbox. Even though it isn't possible to write to the 
current user's DosDevices directory from say IE EPM, Chrome or Adobe sandbox 
you can instead do the same thing on a per-process basis by calling 
NtSetInformationProcess with the ProcessDeviceMap info class to set the 
process's DosDevices object directory. You can use an unnamed object directory, 
created by calling NtCreateDirectoryObject and add the symlink using 
NtCreateSymbolicLinkObject using the unnamed directory handle as the base. You 
would still need to be able to open a file object (it doesn't seem to bypass 
access check) but you could point the open to a named device object which will 
open from the low privileged sandbox, such as \Device\Afd\XXXX. 

Original comment by fors...@google.com on 4 Feb 2015 at 2:43

[GoogleCodeExporter]

Original comment by fors...@google.com on 14 Apr 2015 at 1:28

• Added labels: CVE-2015-1643

[GoogleCodeExporter]

Fixed in https://technet.microsoft.com/library/security/MS15-038

Original comment by fors...@google.com on 14 Apr 2015 at 5:41

[GoogleCodeExporter]

Original comment by fors...@google.com on 16 Apr 2015 at 10:10

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by fors...@google.com on 21 Apr 2015 at 9:45

• Removed labels: Restrict-View-Commit