A nice little LPE technique which takes advantage of several issues as originally noted by James Forshaw at https://bugs.chromium.org/p/project-zero/issues/detail?id=2082. In particular, by running a program that communicates with the kernel via the CfCreatePlaceholders API, an attacker can exploit an issue within the cloud filter driver cldflt.sys, which runs in kernel mode, whereby placeholder files are not handled appropriately.

As James mentions within his writeup, several issues occur within cldflt.sys when creating placeholder files, which are described below:

1. The FSCTL control code which is sent to the kernel mode filter driver to instruct it to create the placeholder file will result in the filter driver calling FltCreateFileEx() without specifying the IO_FORCE_ACCESS_CHECK or OBJ_FORCE_ACCESS_CHECK flags to force access checks to occur. As calling FltCreateFileEx() effectively calls IoCreateFileEx() with the IO_NO_PARAMETER_CHECKING flag set.
   

For more details on these parameters see https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-iocreatefile which notes that if IO_NO_PARAMETER_CHECKING is used, the parameters are not probed to see if they reside in user mode memory or cause access violations. Looking at https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes also shows that the OBJ_FORCE_ACCESS_CHECK flag will enforce the permission checking of an object prior to using it even if the handle is being opened in kernel mode.

So effectively what is happening is that cause these flags are not being specified, the kernel is implicitly trusting the user’s input and failing to perform appropriate access checks prior to performing the file operation in kernel mode on the user’s behalf.

1. The cloud driver takes in a path which is split up into a base sync path, which is checked for write access, and a filename component, which isn’t checked for path separators. So you can specify one base sync path but multiple path separators in the filename component and essentially trick Windows into thinking that you are writing to one directory that you have write access to, whereas in reality you are writing to a subdirectory of that directory that you might not normally have write access to (again remember that the access checks will be bypassed due to the write operation occurring with KeMode privileges).

2. Whilst the call to FltCreateFileEx() uses the FILE_OPEN_REPARSE_POINT to block directly accessing a reparse point, that only prevents it from attempting to access a mount point directly. If you instead create a subdirectory within the mount point and point it at that instead, it will still access the mount point, allowing you to write the file anywhere you would like.

Combining this all together one can create an exploit that either a) Uses an existing directory that we have write permissions to, and then using the permission check error and the directory path error, we can write a file to one of the subdirectories we wouldn’t normally have access to, or one can use the reparse point bug instead to write a file to anywhere on the system.

Microsoft patched this bug in December 2020 by changing the HsmpOpCreatePlaceholders() function in cldflt.sys to add additional checks. I have only done a preliminary inspection of this function but it appears that there are some new checks for the path, specifically r.e the use of \ characters, and a few jumps were changed in their logic. Unfortunately as the function is rather large at 190 blocks and I don’t have the time to dive into this in depth right now this is as much as I was able to confirm. I also found that if you run the exploit on a patched system you will now get the error message: System.Runtime.InteropServices.COMException (0x8007017C): The cloud operation is invalid. (Exception from HRESULT: 0x8007017C), which was not returned previously when attempting to run the PoC from James Forshaw.