🔒
There are new articles available, click to refresh the page.
Before yesterday0patch Blog

Micropatching Unpatched Local Privilege Escalation in Mobile Device Management Service (CVE-2021-24084 / 0day)

26 November 2021 at 17:59

 


by Mitja Kolsek, the 0patch Team

In June 2021, security researcher Abdelhamid Naceri published a blog post about an "unpatched information disclosure" vulnerability in Windows. The post details the mechanics of the issue and its exploitation, allowing a non-admin Windows user to read arbitrary files even if they do not have permissions to do so. The exploit namely copies file(s) from a chosen location into a CAB archive that the user can then open and read.

Abdelhamid's blog post also provides the timeline of reporting the vulnerability to Microsoft through ZDI in October 2020, Microsoft assigning a CVE ID to the issue and allegedly planning to fix it in April 2021, and the latter not happening in April. Or June. Or July or August or September or October.

While we had noticed Abdelhamid's June disclosure, it didn't seem to be a critical enough issue for micropatching, as we generally don't patch information disclosure bugs.

In November, however, Abdelhamid pointed out that this - still unpatched - bug may not be just an information disclosure issue, but a local privilege escalation vulnerability. Namely, as HiveNightmare/SeriousSAM has taught us, an arbitrary file disclosure can* be upgraded to local privilege escalation if you know which files to take and what to do with them. We confirmed this by using the procedure described in this blog post by Raj Chandel in conjunction with Abdelhamid's bug - and being able to run code as local administrator.

(*) Two conditions need to be met in order for the local privilege escalation to work:

  1. System protection must be enabled on drive C, and at least one restore point created. Whether system protection is enabled or disabled by default depends on various parameters.  
  2. At least one local administrator account must be enabled on the computer, or at least one "Administrators" group member's credentials cached


The Vulnerability

The vulnerable functionality resides under the "Access work or school" settings and can be triggered by clicking on "Export your management log files" and confirming by pressing "Export". At that point, the Device Management Enrollment Service is triggered, running as Local System. This service first copies some log files to the C:\ProgramData\Microsoft\MDMDiagnostics folder, and then packages them into a CAB file whereby they're temporarily copied to C:\Windows\Temp folder. The resulting CAB file is then stored in the C:\Users\Public\Public Documents\MDMDiagnostics folder, where the user can freely access it.

It is the copying to C:\Windows\Temp folder that is vulnerable. Namely, a local attacker can create a soft link (junction) there with a predictable file name that will be used in the above-described process, pointing to some file or folder they want to have copied to the CAB file. Since the Device Management Enrollment Service runs as Local System, it can read any system file that the attacker can't.

Abdelhamid's POC targets the kernel dump files in folder C:\Windows\LiveKernelReports to demonstrate the issue, while we used SAM, SECURITY and SYSTEM files from a restore point folder to achieve local privilege escalation.

The vulnerability has CVE-2021-24084 assigned, but we still consider it a "0day" as no official vendor fix is available.


Our Micropatch

Abdelhamid's blog post suggested that user impersonation during CAB file creation would resolve the issue. While we agree with that, we were concerned that might break some use cases and rather decided to check for the presence of junctions during CAB file creation.

The function we patched is CollectFileEntry inside mdmdiagnostics.dll. This is the function that copies files from C:\Windows\Temp folder into the CAB file, and can be tricked into reading some other files instead.

Our patch is placed immediately before the call to CopyFileW that opens the source file for copying, and uses the GetFinalPathNameByHandleW function to determine whether any junctions or other types of links are used in the path. If they are, our patch makes it look as it the CopyFileW call has failed, thereby silently bypassing the copying of any file that doesn't actually reside in C:\Windows\Temp.

Here is the IDA graph showing our applied patch (green code blocks are patch code; blue code block is a trampoline with the original code).  

 


 

Microsoft's Fix

Microsoft's fix doesn't exist as of this writing, but when it becomes available, we'll describe it here. We find it likely that they'll either use caller impersonation during the CAB file creation, or check for junctions in the process like we did.


Micropatch Availability

This micropatch was written for: 

  1. Windows 10 v21H1 (32 & 64 bit) updated with November 2021 Updates
  2. Windows 10 v20H2 (32 & 64 bit) updated with November 2021 Updates
  3. Windows 10 v2004 (32 & 64 bit) updated with November 2021 Updates
  4. Windows 10 v1909 (32 & 64 bit) updated with November 2021 Updates
  5. Windows 10 v1903 (32 & 64 bit) updated with November 2021 Updates
  6. Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates
 
Windows Servers are not affected, as the vulnerable functionality does not exist there. While some similar diagnostics tools exist on servers, they are being executed under the launching user's identity, and therefore cannot be exploited.

Windows 10 v1803 and older Windows 10 versions don't seem to be affected either. While they do have the "Access work or school" functionality, it behaves differently and cannot be exploited this way. Windows 7 does not have the "Access work or school" functionality at all.

Note that Abdelhamid has also published a related POC for Windows 11 but that POC is actually exploiting a different vulnerability. 

 
Micropatches for this vulnerability will be free until Microsoft has issued an official fix. If you want to use them, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.
 

We'd like to thank Abdelhamid Naceri for finding this issue and sharing details, which allowed us to create a micropatch and protect our users.

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


 


 

 

Micropatch For Remote Code Execution by DNS Administrators (CVE-2021-40469)

19 November 2021 at 17:03


by Mitja Kolsek, the 0patch Team

 

This is a story of a publicly known remote code execution vulnerability that somehow got ignored and mostly overlooked for four and a half years, meanwhile rediscovered a number of times, weaponized, and finally fixed this October with an unexpected acknowledgment.

Back in May 2017, security researcher Shay Ber published details about a vulnerability affecting Windows DNS Service. They found that any member of the DNSAdmins domain group can use their privileges to get the computer running the DNS Service to run arbitrary code as Local System - which equals a complete takeover of said computer. Since many domain controllers are running the DNS Service, this could mean a complete Windows domain takeover.

Note that DNSAdmins is a powerful group: being able to change domain DNS configuration allows one to cause all sorts of problems - but it doesn't automatically allow them to take over the domain. Typically, a DNS administrator is not allowed to login to the computer running the DNS Service (often a domain controller), and configures DNS from their own workstation using a DNS management tool that utilizes remote procedure calls (RPC).

Shay noticed that legitimate functionality of these remote procedure calls, conveniently made available by the Windows dnscmd.exe tool, can be used to remotely configure a DNS Service to load an arbitrary DLL from a network share and execute its code. This is due to the DNS Service checking, upon startup, the presence of registry value ServerLevelPluginDll and, if it exists, loading the DLL from the path specified therein. This value could be set remotely using the dnscmd.exe tool by members of the DNSAdmins group.

After reporting this to Microsoft, Shay was told that "it [would] be fixed by basically only allowing DC administrators to change the ServerLevelPluginDll registry key, and that it [would] be possible to toggle this feature off in future releases."

Although in their write-up Shay generously described the issue as "a cute feature (certainly not a bug!)", it was undeniably a privilege escalation - from non domain admin to domain admin - as well as a remote code execution issue - from computer one can run code on to computer one can't normally run code on.

In any case, the issue got largely forgotten, likely because of its "not a bug" classification, until another security researcher Sean Metcalf brought it up in their article a year and a half later. Fourteen months after that, security researcher Dhiraj Sharma revisited the original article and published a new write-up. Further nine months of nothing happening later, an exploit module got added to Metasploit, making it easier for attackers of all hat colors to exploit this issue. We're not done yet. In April and May 2021, security researcher Phakt wrote a two-part analysis of this issue, further dissecting it and shedding light on the "why" and offering an alternative for using the overly-permissive DNSAdmins group

Finally, this October's Windows Updates brought a fix, assigned the issue CVE-2021-40469, and, surprisingly, acknowledged (only) Yuki Chen, a regular reporter of Windows vulnerabilities, for finding and reporting this to Microsoft.

What a ride.

 

Microsoft's Fix

Microsoft's fix delivered by October 2021 updates did what was promised back in 2017: it introduced a new registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\InternalParameters with permissions only allowing administrators to modify its content. The ServerLevelPluginDll value has been moved from the Parameters key to this new key, making it impossible to change it with permissions provided by the DNSAdmins group. A decent fix, as far as we can tell.

The only thing not fixed were affected Windows servers that aren't receiving official Windows updates anymore: Windows Server 2008 R2 and Windows Server 2008 without Extended Security Updates. This is where we come in.


Our Micropatch

Our micropatch, the whole 19 CPU instructions of it, takes a bit different approach compared to Microsoft's fix. When applied (enabled), our micropatch forces the DNS Service to ignore the ServerLevelPluginDll value even if it's present in the registry. Based on the absolute absence of hits when googling for ServerLevelPluginDll and filtering out articles about exploiting this value, we assess that very few organizations are using this feature, so simply removing it - which our patch effectively does - is the optimal approach. This decision was in line with our goal of using minimal amount of code to fix the vulnerability. However, should a customer report that they're using this feature, we'll replace the patch with one that is functionally closer to Microsoft's.

Source code of our micropatch:



MODULE_PATH "..\Affected_Modules\dns.exe_6.1.7601.24437_Srv2008R2_64bit_NoESU\dns.exe"
PATCH_ID 707
PATCH_FORMAT_VER 2
VULN_ID 7208
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x411a7
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msvcrt.dll!_wcsicmp,dns.exe!0x41171
    
    code_start
        push rdi          ; storing register on stack to keep their values
        push rcx
        push rdx
        push r8
        push r9
       
        call VAR          ; trick to get address of string on stack
        dw __utf16__('ServerLevelPluginDll'), 0
    VAR:
        pop rdx           ; rdx points to string
'ServerLevelPluginDll'
        mov rcx, rdx      ; rcx points to
string 'ServerLevelPluginDll'
        mov rdx, r12      ; rdx points to name of registry value that
                          ; is currently being read from registry
        sub rsp, 20h      ; create home space for the 64bit call
        call PIT__wcsicmp ; compare strings case insensitive
        add rsp, 20h      ; abandon home space
       
        pop r9            ; restoring register values from stack
        pop r8
        pop rdx
        pop rcx
        pop rdi
       
        cmp rax, 0        ; were strings equal?
        je PIT_0x41171    ; if so, bypass reading from registry
       
    code_end
    
patchlet_end

   

 

And the video of our patch in action.



This micropatch was written for: 

  1. Windows Server 2008 (updated with January 2020 Updates - latest before end of support) 
  2. Windows Server 2008 R2 (updated with January 2020 Updates - latest before end of support)

 

To obtain the micropatch and have it applied on your computer(s) along with other micropatches included in a 0patch license, create an account in 0patch Central, install 0patch Agent and register it to your account, then purchase an appropriate 0patch license. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch. For a 0patch trial, contact [email protected]

We'd like to thank Shay Ber for finding this issue and sharing details, which allowed us to create a micropatch and protect our users. Thank you also to Yuki Chen, who appears to have been the one finally pushing the official vendor fix out the door.

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


 


 

 

Micropatching Incompletely Patched Local Privilege Escalation in User Profile Service (CVE-2021-34484)

10 November 2021 at 21:19

 


 

by Mitja Kolsek, the 0patch Team

August 2021 Windows Updates brought a fix for CVE-2021-34484, found and reported by security researcher Abdelhamid Naceri. This vulnerability was considered by Microsoft to be an "arbitrary directory deletion" bug, allowing a locally logged-on attacker to delete a folder on the computer. This, combined with the fact that the attacker must also have credentials of another user who can locally log on to the same computer, made the bug seem fairly uninteresting.

However, Abdelhamid subsequently reviewed Microsotf's fix and found it to be incomplete, bypassable with a small change to the attack script. Furthermore, he confirmed the vulnerability was more impactful than described in Microsoft's advisory, namely enabling local privilege escalation from a regular user to System. Consequently, a write-up and proof of concept were published, which allowed us to analyze the vulnerability and create a micropatch for it. 

 

The Vulnerability

The vulnerability lies in the User Profile Service, specifically in the code responsible for creating a temporary user profile folder in case the user's original profile folder is damaged or locked for some reason. Abdelhamid found that the process (executed as Local System) of copying folders and files from user's original profile folder to the temporary one can be attacked with symbolic links to create attacker-writable folders in a system location from which a subsequently launched system process would load and execute attacker's DLL.

The crux of the attack is in quickly creating a symbolic link in the temporary user profile folder (C:\Users\TEMP) so that when the User Profile Service copies a folder from user's original profile folder, it will end up creating a folder somewhere else - where the attacker would normally not have permissions to create one.

Microsoft, even though believing the vulnerability only allowed for deletion of an arbitrarily "symlinked" folder, made a conceptually correct fix: it checked whether the destination folder under C:\Users\TEMP was a symbolic link, and aborted the operation if so. The incompleteness of this fix, as noticed by Abdelhamid, was in the fact that the symbolic link need not be in the upper-most folder (which Microsoft's fix checked), but in any folder along the destination path.

Admittedly, this bug was not easy to reproduce, as it requires winning a race condition and that depends on lots of factors. Nevertheless, an actual attacker would have an unlimited number of attempts and would not be dismayed by that. A more significant obstacle for them would be obtaining additional user's credentials, which seem to be needed in order to exploit this vulnerability. As stated by Abdelhamid, "it might be possible to do it without knowing someone else password." but until someone finds a way to do so, we shall assume this to be a requirement.

While this vulnerability already has its CVE ID (CVE-2021-33742), we're considering it to be without an official vendor fix and therefore a "0day".


Our Micropatch

Our micropatch extends the incomplete security check from Microsoft's fix to the entire destination path by calling GetFinalPathNameByHandle and thus resolving any symbolic links it may contain. Then, by comparing the original path and the "resolved" path, it determines whether any symbolic links are present; if not, original code execution is resumed, otherwise the creation of a temporary user profile is aborted.

 

Our micropatch (green code blocks) injected in the original code of profext.dll.


Source code of our micropatch:



MODULE_PATH "..\Affected_Modules\profext.dll_10.0.19041.1165_Win10-2004_64-bit_u202110\profext.dll"
PATCH_ID 708
PATCH_FORMAT_VER 2
VULN_ID 7184
PLATFORM win64

patchlet_start
  PATCHLET_ID 1
  PATCHLET_TYPE 2
  PATCHLET_OFFSET 0x15065
  N_ORIGINALBYTES 5
  JUMPOVERBYTES 0
  PIT Kernel32.dll!GetFinalPathNameByHandleW,Kernel32.dll!LocalAlloc,msvcrt.dll!_wcsicmp,profext.dll!0x150c8,Kernel32.dll!LocalFree
  code_start
                         ; original path is on rbx
    mov rcx, 0           ; LMEM_FIXED
    mov rdx, 208h        ; number of bytes to allocate
    sub rsp, 20h         ; home space
    call PIT_LocalAlloc  ; allocates the specified number of bytes on the heap
    add rsp, 20h         ; restore stack pointer
    
    mov rcx, [rsp+40h]   ; hFile, handle to file
    push rax             ; save pointer to heap buffer for _wcsicmp
    push rax             ; save pointer to heap buffer for LocalFree
    mov rdx, rax         ; pointer to allocated memory
    mov r9d, 0           ; type of returned result, FILE_NAME_NORMALIZED
    mov r8d, 208h        ; max length of Windows path, the size of lpszFilePath
    sub rsp, 20h         ; home space
    call PIT_GetFinalPathNameByHandleW ; retrieve final path for the specified file
    add rsp, 20h         ; restore stack pointer
    
    pop rcx              ; pointer to allocated buffer
    lea rcx, [rcx+8]     ; GetFinalPathNameByHandleW returns path with \\?\, we get rid of that
    mov rdx, rbx         ; current path
    sub rsp, 20h         ; home space
    call PIT__wcsicmp    ; compare two null terminated paths
    add rsp, 20h         ; restore stack pointer
    cmp rax, 0           ; are strings equal?
    je END               ; if equal, then no links exist, proceed with normal execution
    
    pop rcx              ; pointer to allocated buffer
    call PIT_LocalFree   ; free allocated buffer
    call PIT_ExploitBlocked ; report exploit attempt
    jmp PIT_0x150c8      ; error out
    
  END:
    pop rcx              ; pointer to allocated buffer
    call PIT_LocalFree   ; free allocated buffer
                         ; and continue with normal execution
  code_end
patchlet_end
   

 

And the video of our micropatch in action. Without the micropatch, exploit works; with the micropatch, corrected code in User Profile Service determines that a destination path contains a symbolic link and aborts the creation of a temporary profile folder.



[Update 11/16/2021: The list below updated with additional supported platforms]

This micropatch was written for: 

  1. Windows 10 v21H1 (32 & 64 bit) updated with October or November 2021 Updates
  2. Windows 10 v20H2 (32 & 64 bit) updated with October or November 2021 Updates
  3. Windows 10 v2004 (32 & 64 bit) updated with October or November 2021 Updates
  4. Windows 10 v1909 (32 & 64 bit) updated with October or November 2021 Updates
  5. Windows 10 v1903 (32 & 64 bit) updated with October or November 2021 Updates
  6. Windows 10 v1809 (32 & 64 bit) updated with May 2021 Updates
  7. Windows Server 2019 64 bit updated with October or November 2021 Updates
  8. Windows Server 2016 64 bit updated with November 2021 Updates
While some older Windows versions also seem to be theoretically affected, the vulnerable code is different there, making the window for winning the race condition extremely narrow and probably unexploitable.
 
 
Micropatches for this vulnerability will be free until Microsoft has issued an official fix. If you want to use them, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.
 

We'd like to thank Abdelhamid Naceri for finding this issue and sharing details, which allowed us to create a micropatch and protect our users. Thanks also to Will Dormann for useful tips on reproducing this issue.

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


 


 

A New 0patch Experience

29 October 2021 at 11:14


Last week we updated 0patch Server and 0patch Central, which brought several new features and capabilities. Let's take a quick look at them:


  • Subscription management: Users can now manage their subscriptions in 0patch Central, including turning auto-renewal on or off, changing the number of licenses in a subscription, switching between annual and monthly payments, and canceling a subscription. Managed service providers can use the "Renew of one term" feature for renewing a license once their customer has committed to another term.

  • Monthly licenses: Before, 0patch was only available as an annual subscription service. From now on, we also support monthly subscriptions, allowing customers to up-scale and down-scale their license count on a monthly basis according to their needs. (A minimum of 20 licenses is required for a monthly subscription.)

  • Changing billing and payment information: Users can change their billing and payment information in 0patch Central now.

  • Registering agents directly to a group: Enterprise users will like this one; before, all deployed agents appeared in the root All Computers group and had to be manually moved to appropriate groups. Now, each group has its own key which can be used for auto-registration via MSI command-line arguments, allowing admins to bulk-deploy 0patch agent to all computers in some existing group in their central management system, and registered these agents directly to an appropriate group in 0patch Central.

  • Computer comments: Each computer now has a comment field that can be used to provide additional details.

  • License comments: Each license now has a comment field that can be used to provide additional details, a feature most requested from managed service providers and resellers.

  • No more duplicate agents: Before, a re-registration of 0patch Agent on the same computer resulted in a duplicate computer in the Computers list. This is now resolved.

 

We hope you'll like the new 0patch Central and 0patch user experience. If you run into any issues, please report them to [email protected].

Your 0patch Team

 

 

Significant 0patch Server Update on October 20, 2021

19 October 2021 at 11:18

Dear 0patch users,

We've listened to you, and now we're delivering some of the features and changes you told us would make your use of 0patch easier. Among them are subscription, billing and payment method management, monthly subscriptions, registering agents directly into groups, faster syncing, no more computer duplicates upon agent re-registration and much more. A detailed list will be published after the server has been updated.

The update will take place on Wednesday, October 20, starting at 8 AM CET and will last for up to 4 hours.

During this time period, the following will apply:

  • 0patch Agents will not be able to sync, but will keep applying all patches that have previously been downloaded. The 0patch icon will turn yellow.
  • 0patch Central will not be available. Instead, a maintenance page will be shown at https://central.0patch.com, with embedded 0patch Twitter feed with latest announcements.
  • Registration of new 0patch accounts will not be possible.
  • Any purchases made via https://0patch.com web site will result in created subscriptions but notification emails (such as account activation email) will be delayed until the server is back up.


Thank you for understanding,

your 0patch Team

[Update: server update was successful, all systems are running normally.]


Micropatches for the "File Extension" URL Scheme (CVE-2021-40444)

27 September 2021 at 13:21

 


 

by Mitja Kolsek, the 0patch Team

September 2021 Windows Updates brought a fix for CVE-2021-40444, a critical vulnerability in Windows that allowed a malicious Office document to download a remote executable file and execute it locally upon opening such document. This vulnerability was found under exploitation in the wild.

 

The Vulnerability

Unfortunately, CVE-2021-40444 does not cover just one flaw but two; this can lead to some confusion:

  1. Path traversal in CAB file extraction: The exploit was utilizing this flaw to place a malicious executable file in a known location instead of a randomly-named subfolder, where it would originally be extracted.

  2. "File extension" URL scheme: For some reason, Windows ShellExecute function, a very complex function capable of launching local applications in various ways including via URLs, supported an undocumented URL scheme mapped to registered file extensions on the computer. The exploit was utilizing this "feature" to launch the previously downloaded executable file with the Control Panel application and have it executed via URL ".cpl:../../../../../Temp/championship.cpl". In this case, ".cpl" was considered a URL scheme, and since .cpl extension is associated with control.exe, this app would get launched and given the provided path as an argument.

The second flaw is the more critical one, as there may exist various other ways to get a malicious file on user's computer (e.g., via the Downloads folder) and still exploit this second flaw to execute such file.

 

Microsoft's Patch

What Microsoft's patch did was add a check before calling ShellExecute on the provided URL to block URL schemes beginning with a non-alphanumeric character - blocking schemes beginning with a dot such as ".cpl" -, and further limiting the allowed set of characters for the remaining string.

Note that ShellExecute function itself was not patched, and you can still launch a DLL via the Control Panel app by clicking the Windows Start button and typing in a ".cpl:/..." URL. Effectively, therefore, support for the "File extension" URL scheme was not eliminated across entire Windows, just made inaccessible from applications utilizing Internet Explorer components for opening URLs. Hopefully remotely delivered content can't find some other way towards ShellExecute that bypasses this new security check.


Our Micropatch

Microsoft's update fixed both flaws, but we decided to only patch the "File extension" URL scheme flaw until someone demonstrates the first flaw to be exploitable by itself.

The "File extension" URL scheme flaw was actually present in two places, in mshtml.dll (reachable from Office documents) and in ieframe.dll (reachable from Internet Explorer), so we had to patch both these executables.

Since an official vendor fix is available, it was our goal to provide patches for affected Windows versions that we have "security-adopted", as they're not receiving official vendor patches anymore. Among these, our tests have shown that only Windows 10 v1803 and v1809 were affected; the File Extension URL scheme "feature" was apparently added in Windows 8.1.

We expect many Windows 10 v1903 machines out there may also be affected, so we decided to port the micropatch to this version as well.

Our CVE-2021-40444 micropatches are therefore available for: 

  1. Windows 10 v1803 32bit or 64bit (updated with May 2021 Updates - latest before end of support)
  2. Windows 10 v1809 32bit or 64bit (updated with May 2021 Updates - latest before end of support) 
  3. Windows 10 v1903 32bit or 64bit (updated with December 2020 Updates - latest before end of support) 


Below is a video of our patch in action. Notice that with 0patch disabled, Calculator is launched both upon opening the Word document and upon previewing the RTF document in Windows Explorer Preview. In both cases, Process Monitor shows that control.exe gets launched, which loads the "malicious" executable, in our case spawning Calculator. With 0patch enabled, control.exe does not get launched, and therefore neither does Calculator.




In line with our guidelines, these patches require a PRO license. To obtain them and have them applied on your computer(s) along with other micropatches included with a PRO license, create an account in 0patch Central, install 0patch Agent and register it to your account, then purchase 0patch PRO.
For a free trial, contact [email protected].
 
Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatches.

We'd like to thank Will Dormann for an in-depth public analysis of this vulnerability, which helped us create a micropatch and protect our users.

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

Micropatching MSHTML Remote Code Execution Issue (CVE-2021-33742)

23 August 2021 at 13:36

 

 

by Mitja Kolsek, the 0patch Team

June 2021 Windows Updates brought a fix for CVE-2021-33742, a remote code execution in the MSHTML component, exploitable via Microsoft browsers and potentially other applications using this component, e.g. via a malicious Microsoft Word document. Discovery of this issue was attributed to Clément Lecigne of Google’s Threat Analysis Group, while Google's security researcher Maddie Stone wrote a detailed analysis. A short proof-of-concept (see Maddie's article) that causes access violation in the browser was written by Ivan Fratric of Google Project Zero.

Our tests showed that out of the Windows versions that we have "security adopted", we were only able to reproduce the vulnerability on Windows 10 v1803 and v1809, so these were the ones we wanted to create a micropatch for.

After reproducing the vulnerability, we looked at Microsoft's patch to see if we could do something similar for the two affected Windows 10 versions that haven't received the official vendor fix.

 


 

As seen on the above image, Microsoft has just added a check to see if the user-influenced value (size of TextData element) that caused memory corruption was greater than 0x1FFFFFFF. If so, it triggers an assertion and effectively crashes the process without trying to resolve the situation. This is a bit unusual as it implies that either (a) Microsoft found it extremely difficult to fix this issue at some root level, issue a JavaScript exception and keep the process running, or (b) they wanted to get this over with quickly because Internet Explorer is hardly supported anymore and MSHTML, while still being used by other applications such as Microsoft Word, is not a critical component for their most important customers.

Be it as it may, our micropatch does the same as looking for a better fix could take us down a rabbit hole for a long time. However, it also records an "Exploit Blocked" event to the local 0patch log so an attack will leave a trace.

Source code of our micropatch:



MODULE_PATH "..\Affected_Modules\mshtml.dll_11.0.17134.2208_32bit_Win10v1803-u202105\mshtml.dll"
PATCH_ID 667
PATCH_FORMAT_VER 2
VULN_ID 7139
PLATFORM win32
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4498d0
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT mshtml!0x75e4f0
    ;0x75e4f0 -> Release_Assert
    
    code_start
        mov eax, ebx            ;Get the size of the string       
        cmp eax, 2000000h       ;Check if the string is shorter than 0x2000000
        jl NOEXPLOIT            ;If it's shorter, continue
        call PIT_ExploitBlocked ;If not shorter, show the popup
        setl cl                 ;flag that controls the behavior of Release_Assert function.
                                ;If it's 0, the function does nothing.
        call PIT_0x75e4f0       ;Call Release_Assert
        NOEXPLOIT:
    code_end
    
patchlet_end

   

 

And the video of our patch in action. Note that in contrast to a typical micropatch that prevents the process from crashing, this micropatch - doing exactly the same as Microsoft's fix - lets the process crash in a controlled, unexploitable way in case an overly long string is encountered.



This micropatch was written for: 

  1. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support) 
  2. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)

 

To obtain the micropatch and have it applied on your computer(s) 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. For a 0patch trial, contact [email protected]

We'd like to thank Clément Lecigne, Maddie Stone and Ivan Fratric of Google for finding this issue and sharing details, which allowed us to create a micropatch and protect our users.

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


 

 

Free Micropatches for "PetitPotam" (CVE-2021-36942)

6 August 2021 at 13:27


 

by Mitja Kolsek, the 0patch Team


Update 8/11/2021-A: August 2021 Windows Updates brought a fix for PetitPotam, which, in contrast to our patch that fixes an impersonation issue and keeps EfsRpcOpenFileRaw request functional, disables the EfsRpcOpenFileRaw request. CVE-2021-36942 was assigned to this vulnerability. More details below in the Microsoft's Patch section.

Update 8/11/2021-B: Neither Microsoft's August fix nor our micropatch seem to have covered all PetitPotam affected code. Both fixed the anonymous attack vector but we're investigating additional authenticated paths now and looking for the best way to patch that too. The most effective PetitPotam mitigation currently remains this RPC filter on all Domain Controllers, although it may be an overly broad measure and could break something, so proceed with caution.  

Update 8/19/2021: After further analysis of additional PetitPotam attack vectors, we created additional micropatches that block all these vectors. Today's PetitPotam patches are written for executables from August 2021 Windows Updates, which means you have to have these updates installed (i.e., fully updated Windows as of this writing) in order to have them applied. 

Update 9/15/2021: September 2021 Windows Updates did not bring any changes regarding the new PetitPotam attack vectors, so our micropatches remain free.


Wow, we're busy these days. Just yesterday we issued micropatches for the "Malicious Printer Driver" 0day, and today we're fixing a critical remote code execution issue that allows an anonymous attacker to take over a Windows Domain Controller: the infamous "PetitPotam" bug.

PetitPotam was discovered by security researcher topotam, who published their proof-of-concept on Github on July 20, 2021. There is no official vendor patch for it at the time of this writing; in fact, Microsoft's support article implies they do not consider this a vulnerability but rather a mis-configuration, and provides some generic mitigations that do not address the root issue.

As usually, CERT/CC vulnerability note by Will Dormann nicely explains the vulnerability and an exploit chain leading to a complete domain takeover. The main problem is that any user - even anonymous - can force a domain controller to send NTLM credentials of its computer account to attacker's server, where these can be received and then relayed to another service in the domain to make a malicious privileged request.

 

Analysis

We took a look at what goes on in the code when an EfsRpcOpenFileRaw request is received by the server. It is function  EfsRpcOpenFileRaw_Downlevel in efslsaext.dll that processes this request. This function has most of its code enclosed in an impersonation block between a call to RpcImpersonateClient and a call to RpcRevertToSelf. Code inside this block is being executed under the identity of the requesting entity (in our case, attacker), while code outside executes as Local System, i.e., the computer account.

Unfortunately, function EfsRpcOpenFileRaw_Downlevel, outside the impersonation block, makes a call to EfsGetLocalFileName, which tries to open the attacker-supplied UNC path. By doing so, it sends local computer's NTLM credentials inside the SMB request to the remote network share. If the attacker is waiting on the other end, they get these credentials.

Let's take a look at relevant parts of function EfsRpcOpenFileRaw_Downlevel:


Beginning of function EfsRpcOpenFileRaw_Downlevel, with the call to EfsGetLocalFilename being called without impersonation

Continuation of function EfsRpcOpenFileRaw_Downlevel

Note that only this call to EfsGetLocalFileName is non-impersonated, while core EFSRPC functionality executes under requester's identity. This means that anonymous or unprivileged user cannot remotely execute EFSRPC functions such as reading or creating arbitrary network files.

 

Micropatch

Our micropatch extends the impersonation block such that it now encloses the previously un-impersonated call to EfsGetLocalFileName; as a result, the SMB request which this function triggers contains attacker's NTLM credentials instead of computer account's. Therefore, in case of an anonymous request the attacker gets credentials of the ANONYMOUS LOGON user (which are of no use), and if they use credentials of a Windows domain user, the acquired NTLM credentials will be of that same user (which they already have).

The patch contains two patchlets, one starting impersonation by calling RpcImpersonateClient,  and another stopping impersonation by calling RpcRevertToSelf.



MODULE_PATH "..\Affected_Modules\efslsaext.dll_10.0.17763.1075_64bit_WinSrv2019-u202107\efslsaext.dll"
PATCH_ID 663
PATCH_FORMAT_VER 2
VULN_ID 7174
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x280c
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT rpcrt4!0x53370,efslsaext!0x288c
    ;0x53370 -> RpcImpersonateClient
    ;0x288c -> Error block
    
    code_start    ;Injected at the top of the block containing
                   EfsRpcGetLocalFileName, in the EfsRpcOpenFileRaw_Downlevel
                   function
        mov rcx, 0        ;Set rcx for RpcImpersonateClient to 0, so it
                           impersonates the current client
        call PIT_0x53370  ;Call RpcImpersonateClient
        mov rbx, rax      ;Move the result to rbx, so it can be used for error
                           reporting in case of failure   
        cmp rax, 0        ;Check if impersonation failed
        jne PIT_0x288c    ;If failed, jump to error block
    code_end
    
patchlet_end

patchlet_start
    PATCHLET_ID 2
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x288c
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT rpcrt4!0x563b0
    ;0x563b0 -> RpcReverToSelf
    
    code_start  ;Injected at the top of the block right after the
                 RpcRevertToSelf call, in the EfsRpcOpenFileRaw_Downlevel function
        call PIT_0x563b0    ;Call RpcRevertToSelf to stop impersonating
    code_end
    
patchlet_end

   

 

Let's look at the difference between running the PetitPotam tool against a fully updated Windows Server without and with 0patch.


Without 0patch

Let's see which user executes the call to EfsGetLocalFileName:


 

As expected, it's Local System. And the PetitPotam tool, chained with Active Directory Certificate Server produces domain controller's certificate:

 


With 0patch

Let's see which user executes the call to EfsGetLocalFileName this time:

 


Good, it's the Anonymous Logon user, which is useless to the attacker. Consequently, the PetitPotam attack doesn't work anymore:

 


Patch Availability

This micropatch was written for:

 

  1. Windows Server 2019 (updated with July 2021 Updates)
  2. Windows Server 2016 (updated with July 2021 Updates)
  3. Windows Server 2012 R2 (updated with July 2021 Updates)
  4. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 

 

Our tests indicate that Windows Server 2012 (non R2), Windows Server 2008 (non R2) and Windows Server 2003 are not affected by this issue.

Micropatches for this vulnerability are, as always, automatically downloaded and applied to all affected computers (unless your policy prevents that), and will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.

Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity mitigation that prevents a 0patch component to be injected in the service (which is okay) but sometimes also does a lot of seemingly meaningless processing that causes process startup to time out. As a result, various licensing-related errors can occur. The issue, should it occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.

Update 8/19/2021: Microsoft's August 2021 updates brought a functionally similar fix as our micropatch, but since other attack vectors were subsequently discovered, we have issued additional micropatches that apply on top of August 2021 Windows executables. In order to use them, you have to have August 2021 Windows Updates applied. In addition, we have found Windows Server 2012 to be affected to these additional vectors and have also covered this Windows version with our new micropatches.


[Update 8/11/2021: added section Microsoft's Patch]

Microsoft's Patch

August 2021 Windows Updates brought Microsoft's official fix for this issue. The associated documentation states: "The EFS API OpenEncryptedFileRaw(A/W), often used in backup software, continues to work in all versions of Windows (local and remote), except when backing up to or from a system running Windows Server 2008 SP2. OpenEncryptedFileRaw will no longer work on Windows Server 2008 SP2. Note: If you are unable to use backup software on Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1 and later, after installing the updates that address this CVE, contact the manufacturer of your backup software for updates and support."

 Let's take a look at this fix.

 


Microsoft's fix is in the same function as our micropatch ( EfsRpcOpenFileRaw_Downlevel in efslsaext.dll), but it sabotages the function so it doesn't work anymore. We actually also sometimes sabotage an entire function if it seems that could affect such a small amount of users that the benefits would outweigh the risk. In fact, we were initially inclined to do it here too as we were unable to find any backup product or mechanism that would be using this function - but then decided to rather fix the obvious bug we had noticed, and keep the function "alive".

Note that Microsoft's fix also includes a hidden undocumented feature: instead of outright sabotaging OpenEncryptedFileRaw, the fix checks an undocumented registry value AllowOpenRawDL (DWORD) under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EFS; if this value exists and is equal to 1, OpenEncryptedFileRaw works as before. Therefore, if Microsoft's fix broke your backup, you can disable it using this value, but doing so will make you vulnerable to the PetitPotam attack.

We find this Microsoft's fix to be appropriate and therefore do not plan to port our PetitPotam micropatch to the August 2021 version of efslsaext.dll unless 0patch users come complaining the fix broke their backup. We also invite any Windows users whose backup got broken by August 2021 Windows Update to contact us at [email protected].

Update 8/11/2021: Neither Microsoft's August fix nor our micropatch seem to have covered all PetitPotam affected code. Both fixed the anonymous attack vector but we're investigating additional authenticated paths now and looking for the best way to patch that too. 

Update 8/19/2021: Our new micropatches released today address these additional attack vectors.

 

Credits

We'd like to thank topotam for sharing details about this vulnerability, and Will Dormann, Benjamin Delpy and Kevin Beaumont for sharing lots of useful insights and context that helped us understand this vulnerability and create this micropatch to protect users.

Please revisit this blog post for updates or follow 0patch on Twitter.

Free Micropatches for Malicious Printer Driver Issue (CVE-2021-36958)

5 August 2021 at 13:15

 


 

by Mitja Kolsek, the 0patch Team

[Update 9/15/2021: September 2021 Windows Updates fixed this vulnerability in effectively the same way our micropatch did. The issue was assigned CVE-2021-36958]

[Update 8/11/2021: August 2021 Windows Updates did not fix this vulnerability. We're therefore porting our micropatch to the August versions of executables.]

 

With PrintNightmare vulnerability still echoing (and still without a complete official fix, in our view), another printing-related issue was found by security researcher Benjamin Delpy that allows a local unprivileged user on a Windows machine to execute arbitrary code as System by installing a malicious printer driver.

In essence, the attacker sets up a printer with a modified driver on a machine they control, and then installs this printer using Point and Print on another Windows computer, gaining full control of said computer. While generally considered a local privilege escalation, this issue could also be used in conjunction with some social engineering to get a remote attacker's code executed on user's machine.

The issue is nicely described in this CERT/CC vulnerability note written by Will Dormann. While Windows have been requiring printer driver packages installed via Point and Print to be signed by a trusted source since 2016, Benjamin discovered that additional executable files can be included in such installation outside the signed package, and these would then be automatically loaded (and their code executed) by the Print Spooler service running as System.


How To Fix This?

In contrast to, say, memory corruption bugs or numeric overflows, this is not a trivial issue to fix; adding signature requirement to queue-specific files would require a lot of code and would be incompatible with the "micro" in micropatching. Disabling the transfer of queue-specific files could do the trick, but might result in confused users when installed printers would suddenly behave differently than before without any notification or warning.

We therefore decided to implement the group policy-based workaround as a micropatch, blocking Point and Print printer driver installation from untrusted servers. This workaround employs Group Policy settings: the "Only use Package Point and Print" first requires every printer driver is in form of a signed package, while the "Package Point and print - Approved servers" limits the set of servers from which printer driver packages are allowed to be installed.

These settings are configurable via registry. Our patch modifies function DoesPolicyAllowPrinterConnectionsToServer in win32spl.dll such that it believes that PackagePointAndPrintOnly and PackagePointAndPrintServerList values exist and are set to 1, which enables both policies and keeps the list of approved servers empty.

Of course, if one has not previously configured Point and Print-related group policy settings, our patch breaks Point and Print driver installation because no servers are approved. On the other hand, on computers which already have these policies enabled, our patch has no effect. The reasoning behind our approach was that many Windows users and admins don't even know they're affected by this issue and just having 0patch installed will automatically resolve this vulnerability for them.

Our micropatch has four tiny patchlets:



MODULE_PATH "..\Affected_Modules\win32spl.dll_10.0.19041.746_32bit_Win10-2004-u202107\win32spl.dll"
PATCH_ID 660
PATCH_FORMAT_VER 2
VULN_ID 7172
PLATFORM win32
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4ff70
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    
    code_start
        mov eax, 0   ; we say that registry key PackagePointAndPrint exists
 
       add esp, 0Ch ; align stack pointer
    code_end
    
patchlet_end
patchlet_start
    PATCHLET_ID 2
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x4ff8e
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    
    code_start
        mov eax, 0            ; we say
that value PackagePointAndPrintOnly exists
        add esp, 18h          ; align stack pointer
        mov dword[ebp-2Ch], 1 ; value of PackagePointAndPrintOnly is 1
    code_end
    
patchlet_end
patchlet_start
    PATCHLET_ID 3
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x50018
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    
    code_start
        mov eax, 0   ; we say that registry key PackagePointAndPrint exists
 
       add esp, 0Ch ; align stack pointer
    code_end
    
patchlet_end
patchlet_start
    PATCHLET_ID 4
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x50039
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 5
    
    code_start
        mov eax, 0            ; we say that value PackagePointAndPrintServerList exists
        add esp, 18h          ; align stack pointer
        mov dword[ebp-2Ch], 1 ; value of PackagePointAndPrintServerList is 1
    code_end
    
patchlet_end

   

 

And the video of our patch in action:



This micropatch was written for:

 

  1. Windows Server 2019 (updated with July 2021 Updates)
  2. Windows Server 2016 (updated with July 2021 Updates)
  3. Windows Server 2012 R2 (updated with July 2021 Updates)
  4. Windows Server 2012 (updated with July 2021 Updates)
  5. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 
  6. Windows Server 2008 R2 (updated with January 2021 Updates, first year of Extended Security Updates only) 
  7. Windows Server 2008 R2 (updated with July 2021 Updates, second year of Extended Security Updates) 
  8. Windows 10 v21H1 (updated with July Updates)
  9. Windows 10 v20H2 (updated with July Updates)
  10. Windows 10 v2004 (updated with July Updates) 
  11. Windows 10 v1909 (updated with July Updates) 
  12. Windows 10 v1903 (updated with December 2020 Updates - latest before end of support)
  13. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support) 
  14. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)
  15. Windows 10 v1709 (updated with October 2020 Updates - latest before end of support)
  16. Windows 7 (updated with January 2020 Updates, no Extended Security Updates)
  17. Windows 7 (updated with January 2021 Updates, first year of Extended Security Updates only)
  18. Windows 7 (updated with July 2021 Updates, second year of Extended Security Updates)


Micropatches for this vulnerability will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.

Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity mitigation that prevents a 0patch component to be injected in the service (which is okay) but sometimes also does a lot of seemingly meaningless processing that causes process startup to time out. As a result, various licensing-related errors can occur. The issue, should it occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.

 

What to do if the patch breaks printing?

If printing in your network utilizes Point and Print, our patch can cause problems such as users being unable to print to their printers or even seeing them on a network share. If this happens, we recommend adding servers hosting your printers to the approved server list as follows:

  1. Launch mmc.exe as administrator
  2. Select File -> Add/Remove Snap-in
  3. Add "Group Policy Object Editor"
  4. Under Computer Configuration -> Administrative Templates -> Printers, open the "Package Point and print - Approved servers" policy
  5. Enable the policy, click the "Show" button, and add the servers your printers are on to the list

 

Credits

We'd like to thank Benjamin Delpy for sharing details about this vulnerability, and Will Dormann and Kevin Beaumont for sharing lots of useful insights and context that helped us create this micropatch and protect 0patch users.

Please revisit this blog post for updates or follow 0patch on Twitter.

 

 

 

 

0patch Agent 21.05.05.10500 released

12 July 2021 at 16:20


 

Today we released a new version of 0patch Agent that fixes some issues reported by users or detected internally by our team. We always recommend keeping 0patch Agent updated to the latest version, as we only support the last couple of versions; not updating for a long time could lead to new patches no longer being downloaded and agent not being able to sync to the server properly. 

Enterprise users can update their agents centrally via 0patch Central; if their policies mandate automatic updating for individual groups, agents in such groups will get updated automatically.

Non-enterprise users will have to update 0patch Agents manually by logging in to computers with 0patch Agent and pressing "GET LATEST VERSION" in 0patch Console. We're still offering a free upgrade to Enterprise so any PRO user can request Enterprise features by contacting [email protected].

The latest 0patch Agent is always downloadable from https://dist.0patch.com/download/latestagent.


Release Notes


  • "Hash caching" was introduced to significantly reduce the amount of CPU and disk I/O operations when calculating cryptographic hashes of executable modules as these are loaded in running processes. Before, hash calculation was causing performance problems for some users on Citrix and Terminal Servers.
  • Huge log files are a thing of the past. We have implemented a mechanism to keep log sizes limited, with these limits configurable via registry.
  • 0patch Agent used to have the default Windows API behavior when it comes to using SSL/TLS versions, which was causing problems for users requiring TLS 1.1 or 1.2 on older Windows systems and required manual configuration. The new agent supports TLS 1.1 and 1.2 even on older systems such as Windows 7 or  Server 2008 R2 by default.
  • 0patch Console no longer crashes if launched while another instance of 0patch Console is already running. Now, launching a second 0patch Console puts the already running console in the foreground.
  • 0patch Console's registration form had "SIGN UP FOR A FREE ACCOUNT" and "FORGOT PASSWORD" links swapped. This has been corrected.
  • With 0patch FREE, some notifications occasionally failed to get closed and were left hovering indefinitely, making it impossible for users to reach the screen area behind them. This has been corrected.

 

An enormous THANK YOU to all users who have been reporting technical issues to our support team, some of you investing a lot of time in investigating problems and searching for solutions or workarounds. You helped us make our product better for everyone!

WARNING: We have users reporting that various anti-virus products seem to detect the new agent as malicious and block its installation or execution. Specifically, Kaspersky detects the MSI installer package as malicious (preventing installation and update), while Avast and AVG detect 0patchServicex64.exe as malicious (preventing proper functioning of the agent). We recommend marking these as false positives, restoring quarantined files and making an exception for these files if affected.


 

 

 

Free Micropatches for PrintNightmare Vulnerability (CVE-2021-34527)

2 July 2021 at 13:34


by Mitja Kolsek, the 0patch Team


Update 8/11/2021: August 2021 Windows Updates brought a fix for PrintNightmare that has the same default effect as our micropatch, although with a different implementation; therefore our micropatch is no longer free but available with a 0patch PRO license.

Update 7/16/2021: We've ported and issued our PrintNightmare patches for Windows computers that have July 2021 Windows Updates installed (which we do recommend). Our patches prevent exploitation of PrintNightmare even if computer settings render Microsoft's patch ineffective, as described by Will Dormann's diagram. These patches remain free for now.

Update 7/15/2021: July Patch Tuesday patches included the same PrintNightmare fix as the July 6 out-of-band Windows Update, with Microsoft stating that it properly resolves the vulnerability. As this diagram shows, two configuration options that aren't inherently security-related can make the system vulnerable to at least local - but likely also remote - attack, so we're going to port our patches to at least July Windows Updates while we continue to assess the situation. Since July Windows Updates also brought fixes for various other vulnerabilities, we recommend applying them to keep your computers fully up-to-date.

Update 7/7/2021: Microsoft has issued an out-of-band update for the PrintNightmare vulnerability, but the next day this update was found to be ineffective for both local and remote attack vectors. The update does, however, modify localspl.dll on the computer, which means that our existing patches stop getting applied to this module if the update is installed. In other words, if you used 0patch to protect your computers against PrintNightmare, applying the July 6 update from Microsoft makes you vulnerable again. Since we expect Microsoft to issue another modification to localspl.dll next week on Patch Tuesday, we decided not to port our patches to the July 6 version of localspl.dll but rather wait and see what happens next week. Consequently, we recommend NOT INSTALLING the July 6 Windows update if you're using 0patch.

Update 7/5/2021: Security researcher cube0x0 discovered another attack vector for this vulnerability, which significantly expands the set of affected machines. While the original attack vector was Print System Remote Protocol [MS-RPRN], the same attack delivered via Print System Asynchronous Remote Protocol [MS-PAR] does not require Windows server to be a domain controller, or Windows 10 machine to have UAC User Account Control disabled or PointAndPrint NoWarningNoElevationOnInstall enabled. Note that our patches for Servers 2019, 2016, 2012 R2 and 2008 R2 issued on 7/2/2021 are effective against this new attack vector and don't need to be updated.


Introduction

June 2021 Windows Updates brought a fix for a vulnerability CVE-2021-1675 originally titled "Windows Print Spooler Local Code Execution Vulnerability". As usual, Microsoft's advisory provided very little information about the vulnerability, and very few probably noticed that about two weeks later, the advisory was updated to change "Local Code Execution" to "Remote Code Execution".

This CVE ID would probably remain one of the boring ones without a surprise publication of a proof-of-concept for a remote code execution vulnerability called PrintNightmare, indicating that it was  CVE-2021-1675. Security researchers Zhiniang Peng and Xuefeng Li, who published this POC, believed that their vulnerability was already fixed by Microsoft, and saw other researchers slowly leaking details, so they decided to publish their work as well.

It turned out that PrintNightmare was not, in fact, CVE-2021-1675 - and the published details and POC were for a yet unpatched vulnerability that turned out to allow remote code execution on all Windows Servers from version 2019 back to at least version 2008, especially if they were configured as domain controllers.

The security community went scrambling to clear the confusion, identify conditions for exploitability, and find workarounds in absence of an official fix from Microsoft. Meanwhile, PrintNightmare started getting actively exploited, Microsoft has confirmed it to be a separate vulnerability to CVE-2021-1675, assigned it CVE-2021-34527, and recommended that affected users either disable the Print Spooler service or disable inbound remote printing.

In addition to Microsoft's recommendations, workarounds gathered from the community included removing Authenticated Users from the "Pre-Windows 2000 Compatible Access" group, and setting permissions on print spooler folders to prevent the attack.

All these mitigations can have unwanted and unexpected side effects that can break functionalities in production (1, 2, 3), some including those unrelated to printing.


Patching the Nightmare

 

Long story short, our team at 0patch has analyzed the vulnerability and created micropatches for different affected Windows versions, starting with those most critical and most widely used:


  1. Windows Server 2019 (updated with June 2021 Updates)
  2. Windows Server 2016 (updated with June 2021 Updates)
  3. Windows Server 2012 R2 (updated with June 2021 Updates)
  4. Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates) 
  5. Windows 10 v21H1 (updated with June 2021 Updates)
  6. Windows 10 v20H2 (updated with June 2021 Updates)
  7. Windows 10 v2004 (updated with June 2021 Updates) 
  8. Windows 10 v1909 (updated with June 2021 Updates) 
  9. Windows 10 v1903 (updated with December 2020 Updates - latest before end of support)
  10. Windows 10 v1809 (updated with May 2021 Updates - latest before end of support)
  11. Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)
  12. Windows 10 v1709 (updated with October 2020 Updates - latest before end of support)
  13. Windows 7 (updated with January 2020 Updates, no Extended Security Updates) 

 

[Note: Additional patches will be released as needed based on exploitability on different Windows platforms.]

Our micropatches prevent the APD_INSTALL_WARNED_DRIVER flag in dwFileCopyFlags of function AddPrinterDriverEx from bypassing the object access check, which allowed the attack to succeed. We believe that "install warned drivers" functionality is not a very often used one, and breaking it in exchange for securing Windows machines from trivial remote exploitation is a good trade-off.

Our PrintNightmare patch only contains one single instruction, setting the rbx register to 1 and thus forcing the execution towards the code block that performs said object access check.



MODULE_PATH "..\Affected_Modules\localspl.dll_10.0.19041.1052_64bit_Win10-20H2-u202106\localspl.dll"
PATCH_ID 622
PATCH_FORMAT_VER 2
VULN_ID 7153
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x8f5da
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 8
    
    code_start
        mov ebx, 1       
    code_end
patchlet_end

   


Or as we see it in IDA Pro (green code block is injected by 0patch, grey is the original code that had to be moved in order to inject a jmp instruction in its place to jump to the patch).



 

See our micropatch in action:



Micropatches for PrintNightmare will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.

Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity mitigation that prevents a 0patch component to be injected in the service (which is okay) but sometimes also does a lot of seemingly meaningless processing that causes process startup to time out. As a result, various licensing-related errors can occur. The issue, should it occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.


Frequently Asked Questions


Q: Which Windows versions are affected by PrintNightmare?

Answer updated 7/15/2021: We believe Will Dormann's PrintNightmare diagram most accurately describes the conditions under which PrintNightmare is exploitable, and this applies to all Windows versions at least back to Windows 7 and Server 2008 R2.

We have previously thought that domain-joined computers were not vulnerable but this was likely because by joining a domain, firewall rules were set up that blocked remote exploitation until one started sharing a folder or a printer.

 

Q: How about Windows systems without June 2021 Windows Updates?

We believe that without June 2021 Windows Updates, all supported Windows systems, i.e., all servers from 2008 R2 up and all workstations from Windows 7 and up, are affected.


Q: What will happen with these micropatches when Microsoft issues their own fix for PrintNightmare?

[Update 7/15/2021: We recommend everyone continues applying regular Windows Updates, including specifically the July Patch Tuesday update.]

First off, we absolutely usually recommend you do install all available security updates from original vendors [Update 7/8/2021: For the first time ever we do NOT recommend installing the July 6 update if you're using 0patch. See the top of the article for more information].When Microsoft fixes PrintNightmare, their update will almost certainly replace localspl.dll, where the vulnerability resides, and where our micropatches are getting applied. Applying the update will therefore modify the cryptographic hash of this file, and 0patch will stop applying our micropatches to it. You won't have to do anything in 0patch (such as disabling a micropatch), this will all happen automatically by 0patch design.

When the official fix is available, our micropatches will stop being free, and will fall under the 0patch PRO license. This means that if you wish to continue using them (and many other micropatches that the PRO license includes), you will have to purchase the appropriate amount of licenses.

[Update 7/8/2021: We do not consider Microsoft's July 6 out-of-band updates to be a proper fix, so we're keeping our PrintNightmare patches free until they issue a correct fix.]


Q: I have installed 0patch but the PrintNightmare patch is not applied. Why?

The Print Spooler service doesn't initially load localspl.dll when you start it, so it's probably not loaded yet. When it's needed (e.g., when installing a new printer, probably also when you print, and certainly if you launch a PrintNightmare proof-of-concept or exploit against it), localspl.dll gets loaded, and patched by 0patch.

To be sure you have the correct version of localspl.dll, launch 0patch Console and open the PATCHES -> RELEVANT PATCHES tab. At least one PrintNightmare patch should be listed there.


Q: We have a lot of affected computers. How can we prepare for the next Windows 0day?

Obviously deploying 0patch in an enterprise production environment on a Friday afternoon is not something most organizations would find optimal. As with any enterprise software, we recommend testing 0patch with your existing software on a group of testing computers before deploying across your network. Please contact [email protected] for setting up a trial, and when the next 0day like this comes out, you'll be ready to just flip a switch in 0patch Central and go home for the weekend.


Credits

We'd like to thank Will Dormann of CERT/CC for behind-the-scenes technical discussion that helped us understand the issue and decide on the best way to patch it.


Please revisit this blog post for updates or follow 0patch on Twitter.

Micropatch for Another Remote Code Execution Issue in Internet Explorer (CVE-2021-31959)

14 June 2021 at 13:45

 


by Mitja Kolsek, the 0patch Team


June 2021 Windows Updates brought a fix for another "Exploitation More Likely" memory corruption vulnerability in Scripting Engine (CVE-2021-26419) discovered by Ivan Fratric of Google Project Zero, very similar to this vulnerability discovered also discovered by Ivan and patched in May.

Ivan published details and a proof-of-concept three days ago and we took these to reproduce the vulnerability in our lab and create a micropatch for it.

Since Microsoft's patch was available, we reviewed it and found their patch for it in function ByteCodeGenerator::EmitScopeObjectInit, which Ivan also identified as the source of the flaw. An initialization loop was added to this function to initialize all members of the PropertyID array.

Our micropatch is logically identical to Microsoft's:



MODULE_PATH "..\Affected_Modules\jscript9.dll_11.00.9600.19867_32bit\jscript9.dll"
PATCH_ID 614
PATCH_FORMAT_VER 2
VULN_ID 7138
PLATFORM win32
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x10d189
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9.dll!0x10cf2d
    ; jscript9.dll!0x10cf2d -> SaveToPropIdArray
    
    code_start
        mov ecx, [ebp-0ch]  ;
get linked list
        mov eax, [ecx+0x28] ;
        mov esi, [eax+0x30] ;
       
    LOOP:
        test esi, esi       ; is there more of PropertyID array?
        jz END              ; if everything is initialized, jmp to
                            ; label END, else go into loop.

        mov ecx, [esi+20h]
        lea eax, [ebp-20h]  ; get struct Js::PropertyIdArray *
        push eax            ; struct Js::PropertyIdArray *
        push ebx            ; struct Symbol *
        mov edx, edi        ; struct FuncInfo *
        call PIT_0x10cf2d   ; call SaveToPropIdArray
        mov esi, [esi+18h]  ; next element in linked list
        jmp LOOP
       
    END:
    code_end
   

 

See the micropatch in action:




We'd like to thank  Ivan Fratric for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.
 
This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows versions we've security-adopted:
 
  1. Windows 7 and Windows Server 2008 R2 without Extended Security Updates, 
  2. Windows 7 and Windows Server 2008 R2 with year 1 of Extended Security Updates.
  3. Windows 10 v1803
  4. Windows 10 v1809

To obtain the micropatch and have it applied on your computer(s) 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. 

By the way, if your organization has Windows 10 v1803, Windows 10 v1809 or Office 2010 installations that stopped receiving security updates, and would like to continue using them, it could be useful to know we've security-adopted these for at least 12 months. To save time and money, and step into the age of reboot-less security patching, contact [email protected]com.

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




 

Micropatch for Remote Code Execution Issue in Internet Explorer (CVE-2021-26419)

18 May 2021 at 15:23

 


by Mitja Kolsek, the 0patch Team


May 2021 Windows Updates brought a fix for an "Exploitation More Likely" memory corruption vulnerability in Scripting Engine (CVE-2021-26419) discovered by Ivan Fratric of Google Project Zero. Ivan published details and a proof-of-concept the next day, and we took these to reproduce the vulnerability in our lab and create a micropatch for it.

Since Microsoft's patch was available, we reviewed it and found they only changed function ByteCodeGenerator::LoadCachedHeapArguments such that instead of calling ByteCodeGenerator::EmitPropStore, it now calls ByteCodeGenerator::EmitLocalPropInit.These are undocumented and largely unknown functions but their names imply the vulnerability resides in just-in-time compiler's code generation logic, where the generated code gets an improper level of access to the arguments object.

Our micropatch is logically identical to Microsoft's:



MODULE_PATH "..\Affected_Modules\jscript9.dll_11.0.9600.19867_64bit\jscript9.dll"
PATCH_ID 606
PATCH_FORMAT_VER 2
VULN_ID 7112
PLATFORM win64
patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0xbe342
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT jscript9!0x8be60 ; ByteCodeGenerator::EmitLocalPropInit
    
    code_start
        mov r9, rbp ; Some instructions are erased and a new function call added
        mov r8, rdi
        mov edx, esi
        mov rcx, rbx
        mov rbx, [rsp+70h]
        add rsp, 40h
        pop rdi
        pop rsi
        pop rbp
        jmp PIT_0x8be60 ; New call to EmitLocalPropInit
    code_end
    
patchlet_end

 

See the micropatch in action:




We'd like to thank  Ivan Fratric for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows 7 and Windows Server 2008 R2 machines without Extended Security Updates, or with year 1 of Extended Security Updates.

To obtain the micropatch and have it applied on your computer(s) 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. 

By the way, if your organization has either Windows 10 v1809 or Office 2010 installations that stopped receiving security updates, and would like to continue using them, it could be useful to know we've security-adopted both for at least 12 months. To save lots of money and step into the age of reboot-less security patching, contact [email protected].

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




 

0patch Security-Adopts Windows 10 v1803 and v1809 to Keep it Running Securely

11 May 2021 at 08:05

Towards Micropatching the "Security Update Gap"

 


by Mitja Kolsek, the 0patch Team

 

[Update: We initially security-adopted only Windows 10 v1809, but were then approached by customers needing micropatches for v1803 as well, so we security-adopted that version too.]

The May 2021 Windows Updates will contain the last official security fixes for many editions of three Windows 10 operating system versions:

  1. Windows 10 v1803
  2. Windows 10 v1809
  3. Windows 10 v1909

For organizations with any of these versions installed on their computers, this means the end of official security patches, and a pressure to upgrade to a supported Windows 10 version. Such organization-wide operating system upgrade may seem like a simple, mostly automated task - but in reality, updates break things:

In addition, with many users working from home these days, upgrading an operating system involves users downloading a huge update via their home Internet connection and difficult remote assistance in case something goes wrong with the upgrade.

Consequently, customers were approaching us in recent months asking whether we were planning to security-adopt some of these Windows 10 versions (mostly version 1809, later also version 1803), as they were looking for ways to keep using them securely.

And so we've decided to security-adopt Windows 10 v1803 (build 10.0.17134) and v1809 (build 10.0.17763) - as we have previously security-adopted Windows 7, Windows Server 2008 R2, and Office 2010.

Starting this month, initially for one year, we will actively gather information about vulnerabilities affecting Windows 10 v1803/v1809 and, based on our risk criteria, create micropatches for this operating system. We will be particularly interested in any vulnerabilities patched by Microsoft in still-supported Windows 10 versions, and whether they might affect v1803/v1809 as well.

These micropatches will be included in 0patch PRO and Enterprise licenses along with all other micropatches we're issuing - which means that users protecting their Windows 10 v1803/v1809 with 0patch will also receive our occasional micropatches for "0day" vulnerabilities in various products.

In order to have our Windows 10 v1803/v1809 micropatches applied, users will have to have their computers fully updated with the latest (May 2021) official Windows Updates provided by Microsoft.

We welcome all interested organizations with Windows 10 v1803/v1809 to contact [email protected] for information about pricing, deployment, or setting up a trial. If you happen to be using a large number of v1909 versions in your environment, also let us know as given sufficient demand we will security-adopt those too.

 

Addressing The Security Update Gap 

Our security-adoption of an unsupported Windows 10 version is an important milestone on our journey towards addressing the "security update gap" on supported Windows versions, which aims to allow organizations to protect themselves with our micropatches while thoroughly testing monthly Windows Updates before deploying them. And eventually even skipping one or two monthly updates under our protection.

 

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


 

 

 

Another Windows Installer Local Privilege Escalation Bug Gets a Micropatch (CVE-2021-26415)

6 May 2021 at 14:24

 


by Mitja Kolsek, the 0patch Team


On April 21, security researcher Adrian Denkiewicz published an in-depth analysis of a local privilege escalation vulnerability in Windows Installer that was fixed by April 2021 Windows Updates. Adrian's analysis included a proof-of-concept.

The vulnerability is a classical symbolic-link issue, whereby a privileged process (in this case, msiexec.exe) works with a file (in this case, installer log file) that the attacker is able to "redirect" to another location where the they do not have permissions to create or modify files.

Since attacker has limited control over the content of installer log file, and cannot modify the redirected log file after it has been created, Adrian had to be creative and found a working attack scenario in creating/overwriting PowerShell profile file (C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1) that gets loaded whenever anyone, ideally admin, uses PowerShell.

In essence, Microsoft's fix included a call to function IsAdmin from function CreateLog, which is in charge of creating installer log file. Some permissions checking was already in place before in this function but was not resilient to the "bait-and-switch" symbolic link trick that has been successful against many Windows products before, and will surely be successful against many more to come.

Our micropatch does logically the same as Microsoft's fix. Here is its source code for 64-bit Windows 7 and Server 2008 R2 with its 7 CPU instructions.



MODULE_PATH "..\Affected_Modules\msi.dll_5.0.7601.24535_64bit\msi.dll"
PATCH_ID 604
PATCH_FORMAT_VER 2
VULN_ID 7058
PLATFORM win64

patchlet_start
 PATCHLET_ID 1
 PATCHLET_TYPE 2
 PATCHLET_OFFSET 0xf5a55               ; First GetCurrentThread block in CreateLog function
                                       ; instruction lea r9, [rsp+98h+TokenHandle]
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 0
    PIT msi.dll!0xf5b31,msi.dll!0xef7f8   ; Address of block to jump to; IsAdmin function
    
    code_start
        push rax                      ;Save the GetCurrentThread return
        push rax                      ;Push one more time to fix stack alignment
        call PIT_0xef7f8              ;Call IsAdmin (ret 1 if admin, 0 if not)
        cmp rax, 0                    ;Check if user is admin
        pop rax                       ;Restore the GetCurrentThread return and fix stack alignment again
        pop rax
        je PIT_0xf5b31                ;If user is not an admin, jump over the scond createfile block
    code_end
    
patchlet_end

 

See the micropatch in action here:




We'd like to thank Adrian Denkiewicz for sharing their analysis and POC, which allowed us to create this micropatch for Windows users without official security updates. We also encourage security researchers to privately share their analyses with us for micropatching.

This micropatch is immediately available to all 0patch users with a PRO license, and is already downloaded and applied on all online 0patch-protected Windows 7 and Windows Server 2008 R2 machines without Extended Security Updates, or with year 1 of Extended Security Updates.

To obtain the micropatch and have it applied on your computer(s) 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 with Extended Security Updates and wouldn't mind saving lots of money on less expensive low-risk security patches in 2021 that don't even need your machines to be restarted, contact [email protected].

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



 

 

 

 

 

 

 

 

 

Remotely Exploitable 0day in Internet Explorer Gets a Free Micropatch

29 March 2021 at 20:44


by Mitja Kolsek, the 0patch Team

 

[Note: This blog post was originally published on February 17, 2021 under URL https://blog.0patch.com/2021/02/remotely-exploitable-0day-in-internet.html but was for some reason deleted. Perhaps it was our fat fingers, perhaps evil forces - we'll never know. We have now reconstructed it from the Internet Archive which is an incredible service that you should donate to if you like this post, as we did.]

[Update 3/19/2021: This issue has been fixed by March 2021 Windows Updates. 0patch users had this critical issue, now assigned CVE-2021-26411, patched since February 17, full 20 days before an official patch became available. Since the official fix is available, this micropatch is no longer FREE and requires a PRO license.]

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.  

Analyzing And Micropatching With Tetrane REVEN (Part 1, CVE-2021-26897)

29 March 2021 at 14:52

 

by Mitja Kolsek, the 0patch Team


March 2021 Windows Updates included fixes for seven vulnerabilities in Windows DNS Server, two of which were marked by Microsoft as "Exploitation More Likely": CVE-2021-26877 and CVE-2021-26897. They were not known to be exploited and no details were publicly available until security researchers Eoin Carroll and Kevin McGrath published their analysis on McAfee Labs blog. Their article included enough information for us to reproduce both vulnerabilities, and then create micropatches for them.

This article will be about CVE-2021-26897, while CVE-2021-26877 will be covered in a parallel article.

These two vulnerabilities were the first we have ever analyzed with the help of Tetrane REVEN, an incredibly powerful reverse engineering tool that allows you to record a virtual machine and then browse or search through all recorded instructions in all processes and the kernel, or taint any data value forward or back in time, across processes and between user and kernel space (plus much more). I wanted to use this opportunity to show how REVEN helped us perform these analyses, which would otherwise have been done with WinDbg and countless re-launching of dns.exe process, having all interesting objects bouncing around on different memory addresses every time.


Analysis

CVE-2021-26897 is a buffer overflow issue, whereby a series of oversized "dynamic update" DNS queries with SIG (signature) records causes writing beyond the buffer boundary when these records are saved to file. DNS server periodically saves all received updates to file (so they don't get lost on restart or crash), and the issue gets triggered by simply waiting for this file write to happen after sending a number of requests, or by stopping the DNS Server service, which was a convenient time saver for us.

Our proof-of-concept (POC) sends ten malformed DNS requests, and upon stopping the DNS Server service, the dns.exe process crashes. Let's use REVEN to see what goes on.

We used a virtual machine with Windows Server 2019 and DNS Server role without March updates to keep it in the vulnerable state. It is important to record as few events (called "transitions") as possible, so "lightening" of a machine - stopping unnecessary services, and disabling Windows Defender and Windows Error Reporting - is generally a good idea. We did not stop any services but did the latter as error reporting gets triggered upon every process crash and, well, executes a lot of instructions. While it's easiest to start and stop recording manually, even one second of extra recording can create tens of millions of unneeded transitions that will just slow down post-processing of the recording. To optimize start and end of recording, REVEN provides a cool trick they call "ASM stubs", which is a fancy name for calling the int3 CPU instruction while having the ecx register set to some magic value. In other words, you can trigger starting and stopping of recording from within the virtual machine you're recording, which means you can start right before the interesting stuff happens, and stop right after it's done.

In our case, the mere sending of malformed DNS requests does not crash the process, but the stopping of the DNS Server service does. So we used our POC to send the requests, and then launched a batch script that started the recording and stopped the service. Before that, we have "abused" the Postmortem Debugging mechanism to make it launch a small executable that stops recording whenever a process crashes - instead of launching a debugger, which postmortem debugging was designed for.

Our recording generated around 1.25 billion transitions.Yes, that's billion. But it's really no problem because REVEN handles that effortlessly. The only price you pay for a larger recording is the time you have to wait for REVEN to "replay" it, which extracts all machine states and transitions, indexes them, extracts everything that was happening to the memory, downloads symbol files and a bunch of other things to assure a swift analysis thereafter. Our replay took just over an hour and generated 55 GB of data, upon which the analysis would then actually be done.

Granted, we could have tried to further reduce the recording and possibly succeed, but that doesn't make too much sense - one hour for preparation while you're having lunch is more than acceptable, and fiddling with recording optimization also takes time that can quickly exceed the time saved by a potentially quicker replay.

Proceeding to "Axion", the analysis user interface where the magic stuff happens. Axion has multiple widgets; prominently positioned in the middle are Transitions, displaying a small part of the entire recorded execution conveniently grouped in code blocks with one or more CPU instructions. Other widgets include Backtrace (the call stack for the current transition), CPU (register values before and after the current transition), Memory (at chosen address, before or after the current transition, along with the entire history of read and write accesses), Search (immensely useful, allows you to find calls to specific function, or all executions of a specific instruction), Bookmarks, and - my favorite - Taint. REVEN allows you to select any piece of data (e.g., the current value in register r8, or the value at some memory address) and taint it either forward or back in time, to see what this value affects or where it came from, respectively. This is a huge value-add for our analyses - although by no means the only one.

Now let's dive into the analysis. The first thing we need to do is find where dns.exe crashed. Scrolling through a billion+ transitions is obviously out of the question, but we can search for one of the functions that get called when an unhandled exception is thrown. KiUserExceptionDispatch is one such function.

 

 

Search finds a single hit, as expected, and here we are looking at the first executed instruction in this user-space function, as it was launched by kernel's KiExceptionDispatch. (The kernel code is on grey background because we filtered out only user-space execution.) Now we want to see why this exception was thrown. A simple press of the "%" key transfers our to the other end of a call-ret pair, or in our case, to the other end of the kernel call.

 

The "%" key landed us on the exact instruction that caused access violation in function Dns_SecurityKeyToBase64String. It was an attempted write to address r8+1, and the Memory view shows this address to be immediately after a valid memory block, where we see a bunch of A's that were likely written to this buffer in some loop we're probably currently in. We did not use REVEN-IDA integration here but if we did, we would immediately see the code graph for this function in IDA, with the current instruction selected in IDA. And we would see that we are, indeed, in a loop that copies base64-encoded signature value from our DNS request to this buffer that just got overflown, and uses r8 as the destination pointer that gets increased in every iteration. 

(Note that we enabled Page Heap for dns.exe to make it crash immediately on buffer overflow, otherwise the overflow could just corrupt the heap and eventually cause some random malfunction. With Page Heap, every heap buffer is allocated at the very end of a read-write memory block, followed by unallocated memory page - which means any typical buffer overflow will immediately trigger an access violation exception.)

Execution of a loop is shown in REVEN as a repetition of loop instructions, over and over again, but you can of course select any of these instructions and see how registers and memory looked like at that exact moment. What we want here, though, is to see where the buffer was allocated.

If we were in WinDbg, we'd have used the !heap command to get the call stack from the moment the overflown buffer was allocated. In REVEN, however, we can not only find the code that allocated the buffer, but also values of registers and content of memory in that precise moment. The simplest way (that I know of) would be to simply taint register r8 to see where its value came from - going back to the past far enough, at some point its value must have been determined by whoever allocated this buffer, or it would not have pointed to the end of this same buffer now.

However, tainting r8 backward produces too long a path that just keeps bouncing in the loop that we're in. While it eventually gets to where we want to be, it slows down the UI. So our first goal is to get to the beginning of our loop's execution. We copied the address of our access-violation-triggering instruction (0x7ff729ca224a) and went to the Search widget, where we searched for all uses of this address.



Results: this exact instruction has been executed 130705 times in our recording; in other words, it would take a significant chunk of one's lifetime to just scroll up to the start of the loop. However, it only took one press of the "Next" button to get to the first iteration of the loop - because we were already positioned on the last iteration.

 



 

This got us to the very first execution of our instruction in this recording, and we can see that it wrote 0x41 to memory (to the very same buffer it overflowed 130704 iterations later). The 0x41 left to it was written earlier by a similar instruction in the same loop. Now that we're out of the loop, so to speak, let's taint r8 and see where it got from.



We launched tainting for value of register r8 from the current transition, back to some function we selected high in the call stack; we chose function Zone_WriteBackDirtyZones. Why not taint all the way back to the very first transition? Because we're only interested in who has allocated the memory buffer that got overflown, but the taint would go way further back in time because the address of this allocation was influenced by earlier allocations (that's how the heap works) and that is just irrelevant to us.

Tainting identified a couple of hundred transitions, and we're interested in those at the very end of the list (i.e., the earliest ones). When one is often looking for memory allocations, some familiar Windows functions catch one's eye - and RtlAllocateHeap is one of them.



RtlAllocateHeap takes three arguments, allocation size being the third one - which in x64 calling convention means register r8. We can see that the value of r8 when this function was called was 0x80010. This means that the actual buffer allocated was of this size, but we still want to see if this is a hard-coded size or perhaps dynamically calculated. So we go further back in time through the taint results.



In the very first transition found with tainting, inside funtion File_WriteZoneToFile, we see a call was made to a function Mem_Alloc, which is not publicly documented but is clearly used for allocating the memory block we're after. Most importantly, we can see that a hard-coded value 0x80000 was provided to it, which is clearly the size of the buffer. (0x10 was subsequently added to it inside Mem_Alloc, which is nicely seen by walking through the taint.)

Now we know what happened: a fixed-sized memory block was allocated in function File_WriteZoneToFile, whose name implies that the DNS zone we've updated with our malformed requests was going to be written to file. At some point function Dns_SecurityKeyToBase64String was called that overflowed this buffer after base64-encoding the signature from our requests. Let's just see if function Dns_SecurityKeyToBase64String was called more than once, as we know that a single malformed request doesn't produce the crash.

To do that, we used the "Symbol call" search and provided the function name.



The search produced 6 hits, meaning that function Dns_SecurityKeyToBase64String was called 6 times. This indicates that it was our 6th DNS request that finally caused the writing to go beyond the buffer end. Some additional analysis showed that all these calls added their output to the same growing string inside the fixed-size buffer, which was supposed to be finally saved to the zone file.

Our REVEN analysis was done here. At this point we could have created a micropatch in various ways, making sure to prevent writing past the buffer end, but since we had Microsoft's official patches available, we wanted to see what they have done.

We used IDA and BinDiff to compare dns.exe from February 2021 and March 2021, and found 9 functions modified by the March update.



Technically, we could just search our recording for any execution inside these functions, and hopefully find that just one of them was executed - which would mean that the fix was included there. Actually, we did exactly that and found SigFileWrite to be the only one - but this would be very cumbersome if hundreds of functions were modified, especially if the recording included many of the modified functions that have nothing to do with our bug.

The most reliable method would be to inspect the entire taint list to see which of the modified functions affected the value we were tainting. Taint search is currently not supported by REVEN user interface, but we could undoubtedly use the API to achieve that (note to self: send a feature request to Tetrane). We're not that fluent in REVEN API yet so we took the third route: the call stack.

It is quite likely that one of the modified functions would appear in the call stack of our crash instruction. But in our case we don't see it (see the call stack on one of the screenshots above). We do see, however, that function Dns_SecurityKeyToBase64String seems to have been called by function LdrpDispatchUserCallTarget, which has a suspect name. Let's just click on that in REVEN and see what happened there.

 


We see that function RR_WriteToFile made a call to LdrpDispatchUserCallTarget, which then made a jump to SigFileWrite function. The latter is executed, but not seen in the call stack because LdrpDispatchUserCallTarget jumped to it instead of calling. Note that function LdrpDispatchUserCallTarget is part of Control Flow Guard as explained in this Trend Micro article. So whenever you see LdrpDispatchUserCallTarget in the call stack, you'll want to look for which function it jumped to.

Now that we have our "patch suspect", let's see how the original (February) and modified (March) versions of SigFileWrite function compare in BinDiff.



We see that four sanity checks were added, perhaps excessively but efficiently:

  1. If length of the SIG record is less than 0x12 (minimum possible), then exit.
  2. If length of the SIG record, subtracted by 0x12, is less than length of signer's name, then exit.
  3. If pointer to the end of the string (where it will be appended) is larger than end of buffer, then exit.
  4. The final, most complex-looking check, is compiler's "artistic rendition" of multiplication of signature length by 4/3, which is the number of characters that base64-encoding will require. If signature length multiplied by 4/3 is larger than the difference between string end pointer and end of buffer, then exit.

These checks make sure that the buffer will not get overflown, and will silently prevent DNS update records from being written to the zone file if end of buffer has been reached.

 

The Micropatch

Our micropatch does logically the same as Microsoft's, but it also adds an Exploit Blocked alert and log entry in case the buffer would have been overflown, as this would highly likely be a result of an exploitation attempt instead of something that would occur under normal circumstances.



MODULE_PATH "..\Affected_Modules\dns.exe_6.1.7601.24437_64bit\dns.exe"
PATCH_ID 597
PATCH_FORMAT_VER 2
VULN_ID 6993
PLATFORM win64

patchlet_start
    PATCHLET_ID 1
    PATCHLET_TYPE 2
    PATCHLET_OFFSET 0x7be32
    N_ORIGINALBYTES 5
    JUMPOVERBYTES 21            ; eliminate some original instructions that we'll add back in
    PIT dns.exe!0x7be6c
    
    code_start
        movzx eax, word[rdi+0Eh]    ; SIG request length
        cmp ax, 12h            ; is length below 12h?
        jb EXPLOIT_EXIT            ; packet is not valid - jump to exploit exit.
       
        movzx r8d, byte[rdi+42h]    ; get signer's name length (A.mal in the exploit example)
        sub ax, 12h            ; sub 12h from SIG request length
        lea ecx, [r8+2]            ; add 2 to signers name length
        cmp ax, cx            ; compare SIG request length and signer's name length
        jb EXPLOIT_EXIT            ; if signers name length is longer, jump to exploit exit.
       
        sub ax, cx            ; sub signer's name length from SIG request length
        cmp rsi, r11            ; r11 = sprintfSafeA return (end of string), rsi = end of buffer
        jb EXPLOIT_EXIT            ; jump to exploit exit if rsi < r11
       
        movzx r10d, ax            ; r10 = SIG request length - signer's name length
        mov eax, 0x55555556        ; eax = 0x100000000 / 3
        imul r10d            ; edx:eax = r10 * 0x100000000 / 3 (rdx = r10 / 3)
        mov eax, edx            ; eax = r10 / 3
        shr eax, 1Fh            ; eax = lowest bit of (r10 / 3)
        add edx, eax            ; add the lowest bit of eax ro edx (i.e., round up the division)
        lea eax, [4+rdx*4]        ; eax = 4*(rdx+1) - length of the base64-encoded string
        movsxd rcx, eax            ; rcx = length of the base64-encoded string
        mov rax, rsi            ; rax = end of buffer
        sub rax, r11            ; rax = end of buffer - end of existing string (i.e., space available)
        cmp rax, rcx            ; is space available less than length of base64-encoded string?
        jl EXPLOIT_EXIT            ; if so, go to exploit exit
       
        movzx eax, byte[rdi+42h]    ; original code preparing arguments for Dns_SecurityKeyToBase64String call
        lea rcx, [rax+rdi+44h]
        mov edx, r10d
        add rcx, r8
        mov r8, r11
        jmp END
       
    EXPLOIT_EXIT:
        mov r11, 0            ; r11 is later moved to rax which is the return of the function
        call PIT_ExploitBlocked        ; we call Exploit Blocked
        jmp PIT_0x7be6c            ; jump to last function block
    
    END:                    ; continue normal execution
    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 gets the DNS Service to crash (manually stopping the service just makes the crash happen earlier so we don't have to wait). This could be leveraged to remote arbitrary code execution of attacker's code as Local System. With our micropatch applied, the POC is blocked because the corrected code prevents writing beyond the allocated memory buffer.




We created this micropatch for the following Windows versions:

  1. Windows Server 2008 R2 without Extended Security Updates, updated to January 2020
  2. Windows Server 2008 R2 with year 1 of Extended Security Updates, updated to January 2021

According to our guidelines, this micropatch requires a 0patch PRO license. By the time you're reading this, the micropatch has already been distributed to all licensed 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 with appropriate amount of PRO licenses. Note that no computer restart is needed for installing the agent or applying/un-applying any 0patch micropatch.

We'd like to thank Eoin Carroll and Kevin McGrath for their analysis of the vulnerability, 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.  




 


Remotely Exploitable 0day in Internet Explorer Gets a Free Micropatch

17 February 2021 at 16:03

 


 by Mitja Kolsek, the 0patch Team

 

[Update 3/10/2021: March Windows Updates brought an official patch for this critical vulnerability and assigned it CVE-2021-26411. 0patch users had this issue patched since February 17, full 20 days before the official patch became available.]

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.

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

11 February 2021 at 14:54

 

 

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.

❌