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.


 

Poc_TransactionManager_EoP.7z 44.6 KB Download

tm_crash.txt 4.6 KB View Download