SSD Advisory – Windows Installer Elevation of Privileges Vulnerability

TL;DR

Vulnerability in Windows Installer allows local users to gain elevated SYSTEM privileges in Windows.

Vulnerability Summary

Windows Installer is a software component and application programming interface of Microsoft Windows used for the installation, maintenance, and removal of software.

Windows Installer suffers from a local privilege escalation allowing a local user to gain SYSTEM on victim’s machine. Microsoft has made a patch available that addresses this issue.

Credit

Independent security researcher Abdelhamid Naceri (halov) has reported this vulnerability to the SSD Secure Disclosure program.

CVE

CVE-2020-16902

Affected Versions

Windows 7

Windows 8

Windows 10

Windows 2008

Windows 2012

Windows 2016

Windows 2019

Vendor Response

Microsoft has released patches to address this issue, for more details see: CVE-2020-16902 | Windows Installer Elevation of Privilege Vulnerability

Vulnerability Analysis

The vulnerability was first found by sandbox escaper. She posted the write up here.

As noted in the write up, the original vulnerability got addressed in CVE-2019-1415. However, it was possible to bypass the patch – this was reported to Microsoft and they released it via security patches for CVE-2020-0814 and CVE-2020-1302. It now turns out those patches can be bypassed as well.

Here’s the unpatched output of the windows installer output using Process Monitor:

And then here’s the updated version:

As you can see, there’s no call to SetSecurityFile to secure the folder and so setting up the security description in c:\ allows for a race condition – since by default an authenticated user has delete access to subdirectories. This means we can call CreateDirectory(path,&sz) and set sz to our security descriptor. That was the patch for CVE-2020-0814.

But wait, why should the directory be protected from a user?

Windows Installer Rollback Files and Scripts

When you try to install, repair, uninstall something you might notice that there’s a cancel button

According to the Microsoft Documentation when the Windows Installer processes the installation script for the installation of a product or application, it simultaneously generates a rollback script and saves a copy of every file deleted during the installation.

These files are kept in a hidden system directory and are automatically deleted once the installation is successfully completed. If however the installation is unsuccessful, the installer automatically performs a rollback that returns the system to its original state.

So if we can modify the rollback files we can do changes to the machine in the context of the windows installer service which runs as SYSTEM.

As you can see here:

There are probably no race conditions since we can’t access the directory because of the ACL.

The security descriptor doesn’t allow even a user to get read access to the directory.

But there’s still something we can do. As seen above, Windows installer doesn’t create the rollback script directly but rather creates a directory and puts temporary files in it, and then deletes the directory.

However, there’s a weird part when the windows installer checks to see if the directory still exists after it successfully deleted it (see the NAME NOT FOUND). If the directory still exist after Windows Installer deleted it, CVE-2020-1302 resurfaces.

As you can see Windows Installer tries to set the security of the folder, which can be easily abused: since we created the directory, we have the ownership of the directory and will have WRITE_DAC access to the directory. As soon as Windows Installer tries to change the ACL to make it write restricted we change it to give everyone access to the directory.

It should be noted that accessing the rollback is a little bit difficult: the rollback script is created with a security descriptor that allow only SYSTEM and Administrators to access to it, which means that even if we control the c:\config.msi directory we can’t access the rollback script. However as can be seen in CVE-2020-0814, we can move the entire directory and then replace it as, and at this point we would have control over the entire directory and this will allow us to delete or move it.

This means we can move the entire directory into a temporary place and then create it by ourselves and place in it our specially created rollback file which would then be executed. Windows Installer usually makes it harder than it sounds, since the Windows Installer creates the rollback file in the directory using a special sharing method:

As you can see we are only allowed read only access, so any attempt to access to it with delete or write access will result in SHARING_VIOALATION.

We can still do some damage sooner or later as the Windows Installer will close the handle, but then again reopen it when Windows Installer wants to read it after clicking on Cancel. In between these two steps we can to move the directory and replace it.

So far the vulnerability would require a timing attack: pressing on the Cancel button at the right moment. So we need to address it in order to make the LPE work seamlessly.

In order to do that, we’ll use an application called Advanced Installer, used to create MSI packages. This application has a nice feature called Custom Actions:

Clicking on it will show you these options:

Clicking on “Launch File” will bring up:

The interesting option is Fail the installation if the custom action return an error, this what we are looking for an automated rollback. You can also see an option at the bottom called Condition. Let’s see what we can do with it.

As you can see, it asks us for the expression and it expects something like if(condition==true){//then execute}

If you pick the Wizard option (just right of the text box), you can then select Feature and click Next:

We can pick the Feature is being reinstalled:

This will allow us to execute the file only if the package is being repaired, making our exploit no longer require any user interaction.

At this point we have everything ready, we have an MSI package that will fail, will automatically rollback and will execute our code – we just need the Rollback file placed in the right folder and we are set.

Our rollback file will modify the Fax service executable to something we control – since users are allowed to start this service without any special privileges, after the registry was modified we just need to star the service and we get SYSTEM privileges.

Exploit

Because the exploitation of this vulnerability requires building an MSI file and using Bluebear rollback generated file, we will not be providing an exploit for this vulnerability – a working exploit in binary form was provided to Microsoft and used by them to verify the findings.