Windows: Global Reparse Point Security Feature Bypass/Elevation of Privilege(CVE-2018-0822)

Windows: Global Reparse Point Security Feature Bypass/Elevation of Privilege Platform: Windows 10 1709 (functionality not present prior to this version) Class: Security Feature Bypass/Elevation of Privilege Summary: It’s possible to use the new Global Reparse Point functionality introduced in Windows 10 1709 to bypass the existing sandbox limitations of creating arbitrary file symbolic links. Description: Windows 10 introduced mitigations to prevent the abuse of various types of symbolic links when a process is running in a sandbox. This is a combination of outright blocking of the functionality (such as in the case of Registry Key symlinks) to doing checks on the target location so that the sandbox user can write to the location (in the case of Mount Points). Fall Creator’s Update has introduced a new defined reparse tag, the Global Reparse Point (value 0xA0000019) which I assume is for Silo’s where a symlink can be added into the Silo’s visible namespaces which actually redirects to the global namespace. One user of this is the named pipe file system. It seems that nothing prevents you creating this type of reparse point on an NTFS volume, it doesn’t get checked by the kernel for the sandbox mitigation and because the NTFS driver ignores anything which isn’t a mount point or a ntfs symbolic link it will also not check for the SeCreateSymbolicLinkPrivilege. This symbolic link type works to reparse to any file type so you can create either a file or directory symbolic link. The reparse buffer is basically the same as the normal symbolic link one, but with a different tag. In fact strangely the named pipe file system passes back a buffer with the normal symbolic link tag but with the global reparse tag in the data structure passed back to IopParseDevice. Outside of the behavior in sandboxes you might want to check that the reparse buffer is correctly verified. Normally the NTFS driver checks the structure of a reparse buffer using FsRtlValidateReparsePointBuffer but that function doesn’t know about the new reparse tag, so you could end up with completely untrusted data being passed into the object manager (NPFS synthesizes the reparse buffer so normally it would be trusted). I’ve not checked if you could trivially BSoD the machine through this approach. Note that while NTFS symbolic links can be created without privileges in developer mode this bypass also allows a normal user to create them without developer mode being enabled so also acts as an EoP. Proof of Concept: I’ve provided a PoC as a C# project. * 1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work. * 2) Run the poc as Low IL or an in AC passing on the command line the name of the symlink file to create and a target path. For example ‘poc c:\test\hello c:\windows’ will create a symlink ‘hello’ pointing at ‘c:\windows’. Make sure the destination name can be written to as the sandboxed user. * 3) Open the symbolic link as a normal privileged user to see if the reparse target is followed. Expected Result: The creation of the symlink should fail with an error. Observed Result: The symlink is created, is valid and can be used to access the target. [poc.zip](https://bugs.chromium.org/p/project-zero/issues/attachment?aid=310788&signed_aid=6fITwVTvj1A_w-D1KovsZw==)