SandboxEscaper / PoC-LPE: What's Inside?

On Habré there is already news about this vulnerability , but, unfortunately, without technical details. I suggest to look inside the published archive (author - SandboxEscaper ).

Under the cut is a translation of the document description, located in the archive.

Vulnerability description

The Task Scheduler service (task scheduler) has an RPC interface (accessible via the ALPC transport), which supports the SchRpcSetSecurity method.

This is the prototype of this method:

long _SchRpcSetSecurity( 
    [in][string] wchar_t* arg_1, //Task name 
    [in][string] wchar_t* arg_2, //Security Descriptor string 
    [in]long arg_3); 

Tasks created by the task scheduler create the corresponding directory / file in c: \ windows \ system32 \ tasks. Probably, this method is intended for recording DACL tasks located there. But the recording will occur after the impersonation. However, for some reason, the implementation of the method also checks for the presence of the .job file in c: \ windows \ tasks and writes the DACL to it without impersonation . Since a user (even a user in a group of guests) can create files in this directory, we can simply create a hardlink to any other file that we can read. Using this hardlink, we can force the scheduler service (executing with SYSTEM rights) to write an arbitrary DACL (see the second parameter SchRpcSetSecurity) to a file of our choice.

Thus: for any file that is readable, you can change the DACL, which allows you to completely overwrite it.

Exploiting Vulnerability

This vulnerability gives us a really strong primitive! The main problem is that after installation (by default) many important files can be modified only by the TrustedInstaller user (but not the SYSTEM user).

The archive contains a powershell script for listing files that you can control. Just run:
./enumerate.ps1 >output.txt

There are many goals in the system. You can control the Program Files and, if your target file is used by an administrator / another user, the files you have overwritten can be run with the required privileges.

The second problem is that although we can gain control over multiple files, writing them to them is often impossible, because these DLLs are already loaded somewhere for execution. Attempting to write a DACL for a loaded file will result in a shared access error. But the vulnerability can also be used for other types of files that may be a better target than a DLL.

For operation, the selected file is C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll (the directory name may differ, this is taken into account in PoC). It looks like this file belongs to the XPS printer and is not uploaded to the print service by default (it may happen that the file will already be loaded ... but more often it is not).

And when we run a print job using an XPS printer, the service will load this DLL, which we can rewrite. Such an attack vector (hijacking) can be easily applied for something better. I can try to find the best options ... just let me know.

Note : On the old laptop, where Windows 10 has been running for several years, there are two directories prnms003.inf_amd64_ *. The new version does not delete the old one, which means there is no guarantee that FindFirstFile (used in PoC) will find the current directory. Therefore, you can extend the code by overwriting all found printconfig.dll or check the attribute of the last entry in the file and select a new one.

Demo

In the archive you can also find a video with a demonstration: