Thursday, December 2, 2021

Free Micropatches for the "InstallerFileTakeOver" 0day

by Mitja Kolsek, the 0patch Team

 

Wow, this is the third 0day found by the same researcher we're patching in the last two weeks.

Abdelhamid Naceri, a talented security researcher, has been keeping us busy with 0days this year. In January we micropatched a local privilege escalation in Windows Installer they had found (already fixed by Microsoft), and in the last two weeks we fixed an incompletely patched local privilege escalation in User Profile Service and a local privilege escalation in Mobile Device Management Service (still 0days at the time of this writing).

Ten days ago, Abdelhamid tweeted a link to their GitHub repository containing a proof of concept for another unpatched vulnerability in Windows Installer. The vulnerability allows a local non-admin user to overwrite an existing file to which they do not have write access, and then arbitrarily change its content. This can easily be turned into local privilege escalation by overwriting a trusted system executable file with one's own code - as demonstrated by Abdelhamid's POC, which launches a command line window as Local System.

According to Cisco Talos, this vulnerability is being exploited in the wild

Note that this 0day is being referenced by multiple sources as a bypass to CVE-2021-41379, but the researcher who found it claims that is not the case.

 

The Vulnerability

The vulnerability lies in the way Windows Installer creates a RBF (Rollback File), a file that stores the content of all deleted or modified files during the installation process, so that in case rollback is needed, these files can be restored to their originals. The RBF file is created either in folder C:\Config.msi or in folder C:\Windows\Installer\Config.msi, based on some logic that we admittedly don't fully understand. In any case, should the RBF file be created in folder C:\Windows\Installer\Config.msi *, it later gets moved to a known location in initiating user's Temp folder where the files' permissions are also modified to give the user write access. Abdelhamid noticed that a symbolic link can be created in place of the incoming RBF file, which will result in moving the RBF file from  C:\Windows\Installer\Config.msi to some other user-chosen file on the system. Since Windows Installer is running as Local System, any file writable by Local System can be overwritten and made writable by the local user.

It doesn't take a lot of imagination to see that taking over an executable file that is being used by a privileged process can get one's code executed with such process' privileges. This Twitter thread by Will Dormann provides various options to achieve the same.

* In case the RBF file is created in C:\config.msi, the described file move does not take place, and the exploit can't work. Interestingly, Abdelhamid's 0day we had fixed in January was targeting the other rollback file, RBS or Rollback Script, which - to the contrary - had to be created in C:\Config.msi instead of in C:\Windows\Installer\Config.msi, to be exploitable. Things are weird in the Windows Installer world.


Our Micropatch

Our micropatch targets the RBF file move operation, whereby it checks that the destination path does not contain any junctions or links. If it does, we consider it an exploitation attempt, and the operation is canceled. The original code then "thinks" the file move operation has failed for some reason.

Here is the video of our micropatch in action. Without the micropatch, exploit works and a command line window is launched as Local System; with the micropatch, the code we correct in msi.dll determines that destination path contains a symbolic link, aborts the file move operation and triggers an "Exploit blocked" event.



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
  7. Windows 10 v1803 (32 & 64 bit) updated with May 2021 Updates
  8. Windows 10 v1709 (32 & 64 bit) updated with October 2020 Updates 
  9. Windows 7 ESU (32 & 64 bit) updated with November 2021 Updates
  10. Windows Server 2019 updated with November 2021 Updates
  11. Windows Server 2016 updated with November 2021 Updates
  12. Windows Server 2012 R2 updated with November 2021 Updates
  13. Windows Server 2012 updated with November 2021 Updates
  14. Windows Server 2008 R2 ESU (32 & 64 bit) updated with November 2021 Updates
 
Windows 7 and Server 2008 R2 without ESU (Extended Security Updates), which we have security-adopted, do not appear to be vulnerable.

Note that Abdelhamid's POC also works on Windows 11 and likely Windows Server 2022, but we don't support these Windows versions yet. 
 
 
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.

Friday, November 26, 2021

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

 


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.


 


 

 

Friday, November 19, 2021

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



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 Phackt 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 sales@0patch.com

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.


 


 

 

Wednesday, November 10, 2021

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

 


 

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.


 


 

Friday, October 29, 2021

A New 0patch Experience



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 support@0patch.com.

Your 0patch Team

 

 

Tuesday, October 19, 2021

Significant 0patch Server Update on October 20, 2021

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.]


Monday, September 27, 2021

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

 


 

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 sales@0patch.com.
 
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.