Microsoft Windows Print Spooler Elevation of Privilege vulnerability (CVE-2021-1675) explained

I guess most of you heard about the Windows Print Spooler Elevation of Privilege vulnerability (CVE-2021-1675) in the last couple of weeks. It is a vulnerability that gives an attacker high privileges when they own a regular user account on all print spooler service-enabled devices. Unfortunately, it runs on all Windows Operating Systems by default. In this blog post, I will go into the technical aspect of this vulnerability. Remember that CVE-2021-1675 is NOT the same as the Printnightmare (CVE-2021-34527) vulnerability.

Windows Print Spooler Elevation of Privilege

Vulnerability CVE-2021-1675 is an authentication bypass vulnerability found in the AddPrinterDriverEx function.

The AddPrinterDriverEx function installs a local or remote printer driver and links the configuration, data, and driver files. According to Microsoft, “The caller must have the SeLoadDriverPrivilege” privileges to install a driver.

Using whoami, you can check which privileges you have for the current process:

To set the SeLoadDriverPrivileges privileges, you can use a local or domain policy:

Note: Default for workstation and servers administrators have these privileges and default on a domain controller it is the Administrators and Print Operators. The administrator groups’ default groups and users are Domain Administrators, Enterprise Administrators, and the administrator account.

The vulnerability found is that you can bypass the check for SeLoadDriverPrivilege privileges. So basically, any authenticated user can install a local or remote printer driver. When installing a driver, the Microsoft Windows Print Spooler service loads the driver after installing. An attacker uses this to their advantage by installing a malicious payload.

Authentication Bypass

Let us look at the AddPrinterDriverEx function first. To run this function successfully, it requires a set of parameters:

BOOL AddPrinterDriverEx(
  _In_    LPTSTR pName,
  _In_    DWORD  Level,
  _Inout_ LPBYTE pDriverInfo,
  _In_    DWORD  dwFileCopyFlags
);

The most interesting parameter is the dwFileCopyFlags parameter but more on that later.

Let us first attach the spooler service process and see what libraries are loaded. One of the dependencies used by the spooler service is localspl.dll:

Note: The library localspl.dll handles all print jobs directed to printers managed from the local server.

One of the functions localspl.dll contains is SplAddPrinterDriverEx. Here is the SplAddPrinterDriverEx function in pseudocode using Ghidra:

Here it finally gets more technical!

The issue here is that param_4, passed in the SplAddPrinterDriverEx function, is user-controllable, and later in the function, param_4 is used in an if statement.

So if you can control param_4, you can control the if statement. And guess what param_4 is: Correct, dwFileCopyFlags used in the AddPrinterDriverEx function!

So the dwFileCopyFlags, which you use as an argument for the AddPrinterDriverEx function, lets you control the if statement in SplAddPrinterDriverEx. Let us see why this is important.

Looking at the pseudocode, FUN_180020258 is the function to check if the user has SeLoadDriverPrivilege privileges. This function only runs when you enter the if statement. So, skipping this if statement skips the check for SeLoadDriverPrivilege privileges. The if statement only runs if uVar5 is not equal to 0. Luckily for us, uVar5 is set in the if statement, which we control.

To see what is going on, we need to switch to Assembly language:

The BT instruction stands for bit test. Bit Test selects the bit in a bit string (specified with the first operand, called the bit base) at the bit-position designated by the bit offset (specified by the second operand) and stores the value of the bit in the CF flag.

The bit base is DwFileCopyFlags, and the bit-position is 0xf. CMOVNC follows the BT instruction, which stands for “Move if not carry (CF=0)”.

So the bit test instruction selects a bit in DwFileCopyFlags at bit-position 0xf and stores the bit in the CF flag. CMOVNC checks if CF=0, then the condition is satisfied, and uVar5 will be the value of param_7. When uVar5 is not equal to 0, the check for SeLoadDriverPrivilege privileges never executes:

The bit base used in the bit test instruction is DwFileCopyFlags, so we need to look at those flags closer. Using WinDbg, we can see what value DwFileCopyFlags contains when executing the vulnerability:

So the value is 0x8014. When looking at the Proof of Concept code, the argument for DwFileCopyFlags is:

private const uint APD_COPY_ALL_FILES = 0x00000004;
uint flags = APD_COPY_ALL_FILES | 0x10 | 0x8000;

0x00000004 or 0x10 or 0x8000 = 0x8014:

In binary, it is 1000 0000 0001 0100. So the bit test checks if the 15th bit (0xf in hexadecimal) is equal to 0, and if it is, it will enter the if statement.

In this case, the 15th bit is a 1, and uVar5 is set, which results in skipping the SeLoadDriverPrivilege privileges check:

Here is the output of the SeLoadDriverPrivilege privileged skip in WinDbg:

Anyone that can find another combination where the 15th bit is ‘1’ can probably bypass a patch released by Microsoft.

Printnightmare

As mentioned in the beginning: CVE-2021-1675 is NOT the same as the Printnightmare (CVE-2021-34527) vulnerability. Vulnerability CVE-2021-1675 is a local elevation of privilege escalation, and CVE-2021-34527 is a remote code execution vulnerability but more on that in a future blog post!

So, in short, if the 15th bit (counting from 0) is equal to 1, the SeLoadDriverPrivilege check is skipped.

Proof of Concept

I created a C# proof of concept and pushed it to my GitHub to play with the vulnerability.

Conclusion

It took almost 1000 words to explain that the SeLoadDriverPrivilege is skipped when the 15th bit is set to one, but it is an awesome bug, and looking at the many CVE’s in the print spooler, this vulnerability will not be the last.

Special thanks go out to mez0 for not being too annoyed by my stupid questions.