Windows Print Spooler Keeps Delivering Vulnerabilities, And We Keep Patching Them (CVE-2020-1030)

 

 

by Mitja Kolsek, the 0patch Team

 

Security researcher Victor Mata of Accenture published a detailed analysis of a binary planting vulnerability in Windows Print Spooler (CVE-2020-1030), which they had previously reported to Microsoft in May 2020, and a fix for which was included in September 2020 Windows Updates.

The vulnerability (see proof-of-concept) lies - once more - in Print Spooler, this time indiscriminately creating a new "spooler" folder wherever a low-privileged local user instructed it to, doing so as a Local System account and giving said user powerful permissions on such folder. While this "feature" could probably be exploited in many other ways, there is a convenient exploitation target inside the Print Spooler service itself. Namely, the service tries to load a "point and print" driver from folder %SYSTEMROOT%\System32\spool\drivers\<ENVIRONMENT>\4, which does not exist, but can be created using this very "feature".

Microsoft's patch for this issue fixed the way a non-admin user can specify the spooler folder for a printer: Print Spooler service now checks (while impersonating the user) if said user has sufficient permissions to create such folder, including some symbolic link checks to thwart symlink-related shenanigans Print Spooler has been found to be riddled with.

Our micropatch does logically the same, and unfortunately is quite large for a micropatch (172 instructions) because the symlink checks just take a lot of code.

The micropatch was only written for Windows 7 and Windows Server 2008 R2 both (32bit and 64bit) without Extended Security Updates, because other supported systems can (and should) resolve it by applying Windows Updates.

This micropatch has already been distributed to all online 0patch Agents with a PRO license. To obtain the micropatch and have it applied on your computers along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. 

And don't forget, if your organization has Windows 7 or Server 2008 R2 machines pending ESU subscription renewal and wouldn't mind saving lots of money and stress on security patching in 2021 that doesn't even make you restart computers, proceed to this New Year's Resolution.

To learn more about 0patch, please visit our Help Center. 

We'd like to thank Victor Mata of Accenture for publishing their analysis and providing a proof-of-concept that allowed us to reproduce the vulnerability and create a micropatch. We also encourage security researchers to privately share their analyses with us for micropatching.

Micropatches for CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094?

by Mitja Kolsek, the 0patch Team

 

Users are asking about micropatches for CVE-2021-24074, CVE-2021-24086, and CVE-2021-24094, remotely exploitable vulnerabilities in Windows TCP/IP stack that were fixed by February 2021 Windows Updates (and left unpatched on Windows 7 and Server 2008 R2 machines without Extended Security Updates (year 2).

According to Microsoft's blog post on the matter, the two "arbitrary code execution" vulnerabilities are "complex which make it difficult to create functional exploits, so they are not likely in the short term," but that denial-of-service attacks could quickly be devised (from reverse-engineering of patches, we assume).

At the time of this writing (February 10, 2021) we're not developing patches for these vulnerabilities. The main reason is that in order to create a patch, we need to be able to reproduce the vulnerability, i.e., we need to have a proof-of-concept or an exploit that triggers it. None of these have been published or made otherwise available yet. (For the same reasons, they're also not available to attackers.) While we could reverse-engineer patches and try to create our own exploits, our time is better spent on fixing vulnerabilities we (and attackers) already can reliably reproduce, especially if official patches for them do not exist yet (such as this Internet Explorer 0day).

A likely second reason for not patching these vulnerabilities even if we were able to reproduce them would be that these vulnerabilities are likely entirely in Windows kernel, and Microsoft's Patch Guard prevents us from patching kernel code. While this is usually not a problem as most remotely exploitable vulnerabilities are in user space (where we can patch), in this case we recommend implementing Microsoft's workarounds described in respective KB articles, specifically, executing the following on all computers without February 2021 Windows Updates or later:

netsh int ipv4 set global sourceroutingbehavior=drop
netsh int ipv6 set global reassemblylimit=0

According to Microsoft's blog post, network packets that can be used for exploiting these vulnerabilities can also be blocked by firewall, but to protect yourself from internal attackers, making the above Windows systems settings will be more effective.