Wednesday, February 17, 2021

Remotely Exploitable 0day in Internet Explorer Gets a Free Micropatch

 


 by Mitja Kolsek, the 0patch Team

 

On February 4, 2021, security researchers at ENKI, a South Korean security consultancy, published a blog post detailing an unpatched vulnerability in Internet Explorer. This "0day" vulnerability was used in an attack campaign against various security researchers, including ENKI researchers, who noticed the attack and took the exploit apart to extract the vulnerability information. ENKI researchers kindly shared their proof of concept with us, so we could quickly start analyzing the vulnerability and create a micropatch for it.

The vulnerability is a "double free" bug that can be triggered with JavaScript code and causes memory corruption in Internet Explorer's process space. As is often the case, this memory corruption could be carefully managed and turned into arbitrary read/write memory access - which can then be leveraged to arbitrary code execution. Attackers delivered the exploit in an MHTML file to ensure recipients would open it in Internet Explorer (which is registered to open this file type). While this delivery method required recipients to confirm a security warning about executing active content, the exploit could be delivered without such warning if the victim visited a malicious web site with Internet Explorer. 

In such case, just opening the malicious web site would instantly, or a benign web site hosting a malicious ad, would result in malicious native code execution inside Internet Explorer's render process running (by default) in Low Integrity. Such code could read any data from the computer and network that the user running Internet Explorer could read, and silently send it to attacker. An additional vulnerability would be needed to escape the "Low Integrity sandbox" and achieve a long-term compromise of the computer.

Is anyone still browsing the web with Internet Explorer? While Internet Explorer is not widely used for browsing web sites anymore, it is installed on every Windows computer and (a) opens MHT/MHTML files by default, (b) is being used internally in many large organizations, and (c) executes HTML content inside various Windows applications.

 

The Vulnerability

Exploit and proof-of-concept have not been published yet and we won't be the first to do so, but the root of this vulnerability is not new - it's about tricking the browser to delete an object that has already been deleted in some unexpected way that existing sanitization checks don't notice. In this case, it's about deleting a node value of an HTML Attribute. The trick is to create an attribute, assign it a value that is not a string or a number, but an object (why is this even allowed?) - then when deleting this attribute, said object makes sure that the attribute is deleted before it gets deleted, so to speak.

 

The Micropatch

While Internet Explorer developers will probably fix the way the attribute node is deleted so that it doesn't actually get deleted while references to it still exist, we decided that such approach would simply require too much time for us and would introduce an unnecessary risk of breaking something. We thus rather decided to break the obscure browser functionality that allows setting an HTML Attribute value to an object. We assess this functionality to be useful to very few web developers whose apps are supposed to work with Internet Explorer.

Our micropatch gets applied inside the CAttribute::put_ie9_nodeValue function of mshtml.dll, where it checks the VARIANT type of the value that JavaScript code wants to assign to an attribute - and prevents that from happening if the type is 9 (VT_DISPATCH) - which is used for Object, Array, or Date.




The 64bit micropatch only has 5 CPU instructions, and the 32bit one has 6 CPU instructions.

 



MODULE_PATH "..\Affected_Modules\mshtml.dll_11.0.9600.19597_64bit\mshtml.dll"
PATCH_ID 560
PATCH_FORMAT_VER 2
VULN_ID 6943
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0xbf34b4

 N_ORIGINALBYTES 5
 PIT mshtml.dll!0xbf359f ; address of exit block

 code_start

  ; we're going to check the incoming VARIANT's data type; if it's 9 (object), we're going
  ; to prevent it from being copied to the attribute.
  ; The incoming VARIANT is pointed to by rdx, and the type is in the first byte.

  mov r14, rcx         ; replicate the instruction we're injected in front of to make sure
                       ; rcx is stored in r14 in case we jump to the exit block (where rcx is
                       ; restored from r14)
  cmp byte [rdx], 0x09 ; is the incoming VARIANT data type 9 (object)?
  jne DO_NOTHING       ; if not, we don't interfere
 
  mov rbx, 0            ; return value - we simulate a successful operation
  jmp PIT_0xbf359f     ; jump to exit block
 
 DO_NOTHING:

 code_end
    
patchlet_end



Here's a video of the micropatch in action:




The micropatch applies to the following Windows versions (32bit and 64bit). 

Updated to February 2021:

  1. Windows 7 + ESU (first update from ESU year 2)
  2. Windows Server 2008 R2 + ESU (first update from ESU year 2)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019

Updated to January 2021:

  1. Windows 7 + ESU (last update from ESU year 1)
  2. Windows Server 2008 R2 + ESU (last update from ESU year 1)
  3. Windows 10 v1809, v1909, v2004, v20H2
  4. Windows Server 2016, 2019 

Updated to January 2020:

  1. Windows 7 without ESU (last free update without ESU)
  2. Windows Server 2008 R2 without ESU (last free update without ESU)
 

Online Test

 
We have prepared a simple online test to demonstrate how our micropatch changes the behavior of Internet Explorer. To perform this test, you have to use Internet Explorer 11 on one of the Windows systems listed above.

Step 1: With 0patch disabled, open https://0patch.com/poc/IE_Attribute_nodeValue_0day/test.html in Internet Explorer 11. The web page should look like the image below, indicating 6 FAILed tests.

 
Step 2: With 0patch enabled, press F5 to refresh the test page in Internet Explorer 11. The web page should look like the image below, indicating no failed tests.

 
 
According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it. By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), 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.
 
We'd like to thank ENKI researchers for their analysis of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.



While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Thursday, February 11, 2021

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.

Wednesday, February 10, 2021

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.

 

Thursday, January 28, 2021

Windows Installer Local Privilege Escalation 0day Gets a Micropatch

 


by Mitja Kolsek, the 0patch Team

 

[Update 2/9/2021: February 2021 Windows Updates included an official fix for this vulnerability and assigned it CVE-2021-1727. According to our guidelines, this micropatch is no longer FREE, but part of a PRO subscription.]

On December 26, security researcher Abdelhamid Naceri published a blog post with a number of 0days in various security products and a local privilege escalation 0day in Windows Installer. We were mostly interested in the latter.

Abdelhamid provided a proof-of-concept (the GitHub repository is disabled at the time of this writing) which allowed us to quickly reproduce the issue on Windows 10 v2004, but we were having difficulties reproducing it on other Windows 10 versions and older Windows systems. It took us a while to troubleshoot the underlying problem with reproduction and come January 2021 Patch Tuesday, it turned out this vulnerability wasn't patched by Microsoft. Having successfully reproduced the issue by then on all Windows versions back to Windows 7, we decided to create a micropatch to protect Windows users waiting for the official patch. (The micropatch would also be the only available patch for Windows 7 without Extended Security Updates (ESU), or Windows 7 with only the first year of ESU.)


The Vulnerability

This vulnerability is a bypass of Microsoft's fix for CVE-2020-16902 (described by Abdelhamid in detail here), which was itself a bypass of Microsoft's fixes for CVE-2020-0814 and CVE-2020-1302 (also found by Abdelhamid), both of which were a bypass of Microsoft's fix for CVE-2019-1415 (found by SandboxEscaper and described here).

Confusing? Well, some things aren't easy to fix, and Windows Installer is a pretty complex beast that can break a leg if you fix its arm, and then break its tail when you fix the leg. So you want to be careful when fixing.

The core of this vulnerability, and all others listed above, is in tricking Windows Installer into using attacker's own rollback script (a *.rbs file) instead of the rollback script created by msiexec.exe during the installation. See, when installing an MSI package, Windows Installer gradually builds up a rollback script in case the installation should fail at some point, and all changes made up to that point would have to be reverted. But if a local non-admin attacker manages to replace that rollback script with one that "reverts" some system registry value such that it will point to attacker's executable..., well, we get a local privilege escalation.

The proof-of-concept is using a rollback script that changes the value of  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Fax\ImagePath to c:\Windows\temp\asmae.exe, which results in the Fax Service using attacker's asmae.exe when the service is launched. This service was used because any user is allowed to launch it, and it's running as Local System.

As far as this particular 0day goes, Microsoft's fix - which it bypasses - was attempting to block the planting of a malicious rollback script by first determining if it was safe to use the default c:\Config.Msi folder for storing the rollback script, and if not safe, using a different folder, c:\Windows\Installer\Config.Msi, instead. Abdelhamid noticed a logical flaw in this fix, forced Windows Installer to keep using c:\Config.Msi, and then performed the same steps as in his CVE-2020-16902 proof-of-concept to elevate himself to Local System.


Our Micropatch

We confess we do not understand why Microsoft decided to add more complexity with their fix for CVE-2020-16902 when they could have just unconditionally use the c:\Windows\Installer\Config.Msi folder for the callback script and completely avoid numerous attack vectors that c:\Config.Msi is exposed to. Maybe they didn't want to clutter the Windows folder.

Be it as it may, we decided that if Microsoft deemed c:\Windows\Installer\Config.Msi folder to be acceptable for hosting the rollback script under some attacker-controllable conditions, it shouldn't break anything if we forced Windows Installer to always use it for rollback scripts. It is running as Local System so permissions shouldn't be a problem, and a local attacker can't touch this folder in any relevant way.

And here it is, the single-instruction micropatch that fixes this 0day by changing the logic of Microsoft's fix for CVE-2020-16902 such that it now always decides to use c:\Windows\Installer\Config.Msi folder:



MODULE_PATH "..\Affected_Modules\msi.dll_5.0.19041.746_64bit\msi.dll"
PATCH_ID 538
PATCH_FORMAT_VER 2
VULN_ID 6912
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xc2bcc
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    
    code_start
        mov ebx,1    ; use C:\Windows\installer\Config.Msi instead of C:\Config.Msi
    code_end
    
patchlet_end


Here's a video of the micropatch in action. You can see that without our micropatch, the POC, launched by a local non-admin user, successfully modifies a registry value pointing to the Fax Service executable, leading to execution of attacker's code by Local System. With our micropatch applied, the POC is blocked because Windows Installer cannot be tricked into using c:\Config.Msi anymore.




We created this micropatch for the following Windows versions:

  1. Windows 10 v20H2, 32bit and 64bit, updated with January 2021 updates
  2. Windows 10 v2004, 32bit and 64bit, updated with January 2021 updates
  3. Windows 10 v1909, 32bit and 64bit, updated with January 2021 updates
  4. Windows 7, 32bit and 64bit, with ESU, updated with January 2021 updates
  5. Windows 7, 32bit and 64bit, without ESU, updated with January 2020 updates

What about Windows Servers? Fortunately, Windows Servers have a default security policy preventing non-admin users from launching any installations, which successfully prevents exploitation of this vulnerability. Nevertheless, our Windows 7 micropatches will also work on Windows Server 2008 R2, updated to January 2020 (without ESU), or to January 2021 (with ESU) should their system configuration allow non-admin installations.

According to our guidelines, this micropatch is free for everyone until Microsoft issues an official fix for it. By the time you're reading this the micropatch has already been distributed to all online 0patch Agents and also automatically applied except where Enterprise policies prevented that. If you're not a 0patch user and would like to use this micropatch on your computer(s), 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.
 
We'd like to thank Abdelhamid Naceri for their analysis of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.



While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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

Thursday, January 7, 2021

Local Privilege Escalation 0day in PsExec Gets a Micropatch

 

 

by Mitja Kolsek, the 0patch Team

[Update 2/17/2021: Corrected a sentence implying that PsExec may be part of various enterprise tools, while it's just commonly used in conjunction with such tools. (Thanks @wdormann)]

[Update 1/28/2021: Since our publication of micropatch for PsExec version 2.2, PsExec has been updated to versions 2.30, 2.31 and finally 2.32. where it still resides today. David was able to update his POC for each version so the current version 2.32. is still vulnerable to the same attack. Since this version seems to be here to stay for a while, we decided to port our micropatch to it to keep 0patch users with the latest PsExec version protected.]

Last month, security researcher David Wells of Tenable published an analysis of a local privilege escalation vulnerability in PsExec, a powerful management tool from SysInternals (acquired by Microsoft) that allows launching executables on remote computers.
 
It would be hard to find a Windows admin who hasn't used PsExec at some point in time, and just a tiny bit less hard to find one who isn't using it on a regular basis. Granted, some may not even know they're using PsExec because it's commonly used in conjunction with various enterprise tools - tools like JetBrains TeamCity, BMC Server Automation, Chocolatey and SolarWinds Orion.

The Vulnerability

 
The vulnerability is a pretty classic named pipe hijacking (a.k.a. named pipe squatting). When PsExec tries to launch an executable on the remote computer, it creates a temporary Windows service there using PSEXESVC.EXE which it extracts from its own body, launches that service under Local System user, and connects to its named pipe to provide it launch instructions. PSEXESVC.EXE creates the named pipe with permissions that don't allow a non-admin or non-system user to connect to it, which is good because otherwise any user could instruct the service to run arbitrary executable as Local System.
 
Now, the attack comprises a malicious local unprivileged process creating a named pipe with the same name as PSEXESVC.EXE uses, only before the service creates it. PSEXESVC.EXE, running as Local System, subsequently tries to create the same named pipe, but merely re-opens the existing one, leaving its permissions intact. At that point, attacker can connect to the named pipe and make the service run anything.
 
David has provided an elegant proof-of-concept for this vulnerability.
 
So which systems are at risk by this issue? Basically every Windows machine that admins remotely launch executables on using PsExec (or management tools utilizing PsExec) if the machine already has a non-admin attacker there trying to elevate their privileges.


Official Patch? It's... Complicated

 
At the time of this writing, there is no official patch available from Microsoft. PsExec.exe, and PsExec64.exe, which encapsulate the vulnerable PSEXESVC.EXE, are part of the PsTools suite, and were last updated in June 2016. According to Tenable's write-up, PsExec versions from 1.72 (built in 2006) to the latest version 2.2 (built in 2016) are all affected, meaning that the vulnerability has been there for about 14 years. [Update 1/28/2021: current version 2.32 is still affected.]

Note that PsExec is not part of Windows, and is also unlikely to be patchable with Windows Updates as it doesn't even have a designated installation location (one can just copy it anywhere and use it as a standalone executable). PsExec also doesn't have its own integrated update mechanism, meaning that while Microsoft can issue a new, patched version of it and put it on their website, all the vulnerable PsExec's out there will remain vulnerable until admins manually replace them with this new version.


Our Micropatch

 
Let's see how the relevant part of PSEXESVC.EXE looks where named pipe is created and connection requests accepted.



Function CreateNamedPipe is being called in a loop, each time waiting for an incoming request, spawning a new thread to process that request, and repeating the loop.
 
When fixing named pipe hijacking/squatting vulnerabilities, the obvious approach that comes to mind is using the FILE_FLAG_FIRST_PIPE_INSTANCE flag in the CreateNamedPipe call, which only allows the pipe to be created if it is the first instance of the pipe. We actually tried this approach but while it stopped the attack (as attacker's pipe was the first instance), it also broke PsExec because in the above loop, when the first request is accepted and sent for processing, a new instance of the pipe gets created - which is no longer the first instance.
 
So we went for the second best option - checking for existence of the named pipe immediately before the loop. We used a call to CreateNamedPipe with FILE_FLAG_FIRST_PIPE_INSTANCE to determine if a named pipe with this name already exists - and if so, we immediately terminate PSEXESVC.EXE, logging an "Exploit Blocked" event in the process.

Our micropatch has only 21 CPU instructions and should be easy to understand for anyone knowing x86 assembly and Windows API functions:
 


MODULE_PATH "..\Affected_Modules\PSEXESVC.exe_2.2_32bit\PSEXESVC.exe"
PATCH_ID 536
PATCH_FORMAT_VER 2
VULN_ID 6910
PLATFORM win32

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x38ae
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 12
    PIT Kernel32.dll!CreateNamedPipeW,PSEXESVC.exe!0x4e7a,Kernel32.dll!CloseHandle,Kernel32.dll!ExitProcess
    
    ; 0x4e7a -> __swprintf

    code_start   
        ; first three instructions repeated from original code to make
        ; room for the patch JMP
        lea eax, [ebp-414h]        ; buffer for pipe name
        push eax                   ; buffer on stack
        call PIT_0x4e7a            ; call __swprintf
        push 0                     ; lpSecurityAttributes
        push 0                     ; nDefaultTimeOut, A value of zero will result
                                   ; in a default time-out of 50 milliseconds.
        push 10000h                ; nInBufferSize
        push 10000h                ; nOutBufferSize
        push 0ffh                  ; nMaxInstances (the same number must be specified
                                   ; for other instances of the pipe.)
        push 6                     ; dwPipeMode (The same type mode must be specified
                                   ; for each instance of the pipe.)
        push 80003h                ; dwOpenMode - FILE_FLAG_FIRST_PIPE_INSTANCE
        lea eax, [ebp-414h]        ; buffer for pipe name
        push eax                   ; lpName
        call PIT_CreateNamedPipeW  ; Creates an instance of a named pipe and returns
                                   ; a handle for subsequent pipe operations.
        mov edi, eax
        cmp eax, 0xFFFFFFFF        ; check if handle exists
        jne CONTINUE               ; if Handle != -1 (INVALID_HANDLE_VALUE) continue
                                   ; with normal execution
       
        call PIT_ExploitBlocked    ; Exploit blocked pop up
        push -1                    ; uExitCode
        call PIT_ExitProcess       ; Ends the calling process and all its threads.   
    
    CONTINUE:
        push edi                   ; edi = pipe handle
        call PIT_CloseHandle       ; close the pipe handle.
    code_end
    
patchlet_end



Here's a video of the micropatch in action:





According to our guidelines, this micropatch is immediately available to ALL 0patch users for absolutely no cost. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatches.

 

Frequently Asked Questions [Updated 1/28/2021]

 
Q: Which versions of PsExec does the micropatch fix?

A: Our micropatch currently applies to 32bit and 64bit PsExec versions 2.2 and 2.32. We might port it to older versions of PsExec as needed.
 
 
Q: How do we get the micropatch applied?
  1. Create a free 0patch account at https://central.0patch.com.
  2. Download and install 0patch Agent on all computers on which you're running executables with PsExec, then register it to your 0patch account.
  3. Make sure to use PsExec 2.2 or 2.32, or the micropatch won't get applied

Q: Does 0patch Agent have to be running on computers where we run PsExec, or remote computers where executables get launched using PsExec?
 
A: 0patch Agent needs to be running on the remote computers where executables get launched using PsExec. What PsExec does is copy PSEXESVC.EXE to the remote computer (into c:\Windows) and registers it remotely as a service on that computer, then launches that service. This remote PSEXESVC.EXE is what needs to be patched. Note that 0patch Agent can also safely be running on the computer where you run PsExec.
 
 
Q: Can we easily deploy this patch to multiple computers?
 
A: 0patch Agent supports silent (unattended) installation with auto-registration, and central management via 0patch Central. Please see User Manual for details and ask sales@0patch.com for an Enterprise trial.


Q: Will the micropatch also fix PsExec that is integrated into our enterprise product?

A: As long as PsExec used by the product is version 2.2 or 2.32, our micropatch will fix it. But again, 0patch Agent must be present on computers being managed by the enterprise product, not on the machine where said product is installed. If your enterprise product is using another version of PsExec and you cannot replace it, please contact support@0patch.com.


Q: Is there any other way to prevent exploitation of the described vulnerability?

A: Not to our knowledge. Until Microsoft issues a fixed version of PsExec, ours is the only patch that exists.


Q: Is this vulnerability a big deal?

A: Depends on your threat model. This vulnerability allows an attacker who can already run code on your remote computer as a non-admin (e.g., by logging in as a regular Terminal Server user, or establishing an RDP session as a domain user, or breaking into a vulnerable unprivileged service running on the remote computer) to elevate their privileges to Local System and completely take over the machine as soon as anyone uses PsExec against that machine. For home users and small businesses this is probably not a high-priority threat, while for large organizations it may be.



We'd like to thank  David Wells of Tenable for their excellent presentation of the vulnerability and an elegant proof-of-concept, which allowed us to create a micropatch.

While you're here: If your organization has Windows 7 or Server 2008 R2 machines with Extended Security Updates and wouldn't mind saving lots of money on less expensive security patches in 2021 that don't even need your machines to be restarted, proceed to our New Year's Resolution. The same applies if you're still using Office 2010 and want to keep patching critical vulnerabilities now that support has ended.

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