Windows: Desktop Bridge Activation Arbitrary Directory Creation EoP
The activator for Desktop Bridge applications calls CreateAppContainerToken while running as a privileged account leading to creation of arbitrary object directories leading to EoP. As much of the activation of Desktop Bridge applications require TCB privilege (such as creating the container) it’s delegated to the AppInfo service which runs as Local System. During post activation, either through RAiLaunchProcessWithIdentity or RAiFinishPackageActivation the API PostCreateProcessDesktopAppXActivation is called in daxexec which sets up various things. One of those things is registering the process with the Process State Manager service and to do that it passes an AppContainer token for the AppX package. To create the token the service will call the API CreateAppContainerToken, however it doesn’t impersonate the user while doing this which results in the service setting up the AppContainer object directories as the process user. By placing symbolic links into these locations arbitrary object directories can be created, as long as the parent directory can be written by Local System. The created directories are also given an explicit DACL which grants the user access so that they can also be written to by the original user once created. On Windows 8.1 this would be trivial to exploit as NtCreateLowBoxToken didn’t care what handles you passed it for capture, however since CVE-2015-2554 (which I reported) the system call checks that the directories are under the AppContainerNamedObjects directory for the user. They’re still created but once NtCreateLowBoxToken is called they’ll be closed again. However due to the way kernel objects persist it just becomes a race condition, as long as you open the directory you want before all handles are closed then you can keep it alive to do what you need to do with i.e. create a token.
