The LUAFV driver has a race condition in the LuafvPostReadWrite callback if delay virtualization has occurred during a read leading to the SECTION_OBJECT_POINTERS value being reset to the underlying file resulting in EoP. When a IRP_MJ_READ request is issued to a delay virtualized file the filter driver first calls LuafvPreRedirectWithCallback which determines if the file is virtualized, it then sets the underlying, read-only file as the target file object for the filter processing as well as storing the file object in the completion context. When the read operation completes the LuafvPostReadWrite method is called which will inspect the completion context and copy out the file position and the SECTION_OBJECT_POINTERS value. As there’s no locking in place at this point if the file delay virtualization is completed between the call to LuafvPreRedirectWithCallback and LuafvPostReadWrite then the SECTION_OBJECT_POINTERS and cache from the read-only file is used to overwrite the top-level “fake” file object, even though LuafvPerformDelayedVirtualization would have changed them to the new read-write virtual store file. By exploiting this race it’s possible to map the “real” file read-write which allows you to modify the data (you can probably also just write to the underlying file as well). The trick to exploiting this bug is winning the race. One bodge is to just issue a large number of reads to the file and hope that the race is won, however this is unreliable and can take a long time.

The LUAFV driver can confuse the cache and memory manager to replace the contents of privileged file leading to EoP. When using delayed virtualization the driver allows mapping the original file read-only (as a data section or image section) without automatically creating the file in the virtual store. This trick is achieved by copying the real file’s SECTION_OBJECT_POINTERS (SOP) pointer from the file object opened in LuafvDelayOrVirtualizeFile to the top-level “virtual” file object. When creating a new section for a file object the kernel calls MiCreateImageOrDataSection. After checking some parameters it calls MiCallCreateSectionFilters. This is important for virtualization as this results in calling LuafvPreAcquireForSectionSynchronization in the LUAFV driver. If that function detects that the caller is trying to map the section writable then LuafvPreWrite is called which will complete the delayed virtualization process, and will update the SOP pointer of the “virtual” file to the newly created backing file. If the file is not being mapped writable then the LUAFV driver leaves the SOP pointing to the “real” file. MiCreateImageOrDataSection then checks whether the SOP::DataSectionObject CONTROLLING_SECTION_IS_WRITABLE flag is set. If it is then the function will call MiCreateDataFileMap. This function will call MiCreateDataFileMapObject to create a new data file map object. This object is then used to create a new section object. The problem is that the SOP pointer of the “virtual” file object is still pointing to the “real” file. This means that the CONTROLLING_SECTION_IS_WRITABLE flag is set, and MiCreateDataFileMapObject will create a new data file map object for the “real” file. This means that the new section object created will be backed by the “real” file, and not the “virtual” file. This means that an attacker can create a section object backed by a privileged file, and then write to it.

When a caller creates the virtualized file handle the process token is checked for VirtualizationEnabled. If the flag is set and the file create request meets all the criteria for delayed virtualization the driver collates all the necessary information such as the virtual store location for the resulting file if it needs to be copied and stores it in the file object’s context. When a caller performs an operation on the file which is considered a write action, such as writing or issuing any FsControl request then the method LuafvPreWrite is called which will call LuafvPerformDelayedVirtualization. This results in the store file being created and the contents of the original file copied into the new store file before assigning the new file to the original “fake” file object so that the user can continue to use the file. The vulnerability occurs during LuafvPerformDelayedVirtualization. The driver doesn’t take into account the possibility that the virtualized file handle has been duplicated to a new process, specifically one which runs at higher privileges.