Tuesday, May 10, 2022

Micropatches for Remote Desktop Client RCE (CVE-2022-21990)

 

by Mitja Kolsek, the 0patch Team

 

March 2022 Windows Updates brought a fix for a logical vulnerability in Remote Desktop Client for Windows that was found and reported by Abdelhamid Naceri. The vulnerability allowed a malicious RDP server to gain write access to any local drive on the computer running the connected RDP client, as long as at least one local drive was shared through the RDP session.

The trick Abdelhamid used in their POC was, as it so often happens, a symbolic link: Suppose you connected to a malicious RDP server and shared a locally plugged-in USB drive E:, the server could create a symbolic link from E:\temp to C:\ (which would mean your local C: drive, not server's) whereby the entire content of drive C:\ would become accessible to the server under E:\temp with permissions of the connecting user.

Microsoft assigned this issue CVE-2022-21990 and fixed it by preventing the server from creating symbolic links on drives that were shared with the server pointing to drives that were not shared with the server. This fix, however, was not delivered to Windows systems that no longer receive Windows Updates; such systems can now use our micropatches instead.

We decided to make our micropatches simpler than Microsoft's fix to avoid changing lots of code: our approach was to simply prevent creating symbolic links on drives that were shared with the server (regardless where these links would point to). We think it is very unlikely that our approach would break any reasonable use case - but just in case it does, the user can always temporarily disable our patch and then re-enable it - of course without restarting the computer, or even re-establishing the RDP connection.

Our micropatch was written for the following Windows versions that don't receive official patches from Microsoft:


  1. Windows 10 v1803 updated to May 2021
  2. Windows 10 v1809 updated to May 2021
  3. Windows 10 v2004 updated to December 2021
  4. Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
  5. Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020


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

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

We'd like to thank Abdelhamid Naceri 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.

Monday, March 21, 2022

A Bug That Doesn't Want To Die (CVE-2021-34484, CVE-2022-21919)

Twice Bypassed and Twice Micropatched, Will Third Time be a Charm?

 


 

by Mitja Kolsek, the 0patch Team


In November we issued a micropatch for a local privilege escalation in User Profile Service .This vulnerability was found and reported to Microsoft by security researcher Abdelhamid Naceri and assigned CVE-2021-34484 when initially fixed. Abdelhamid subsequently noticed that Microsoft's patch was incomplete and wrote a POC to bypass it. Based on that information, we were able to create a micropatch for what was then considered a 0day (a known vulnerability without an official vendor fix).

Microsoft then provided a fix for Abdelhamid's bypass with January 2022 Windows Updates (assigning the "new" vulnerability CVE-2022-21919), but Abdelhamid took a closer look and found another way around it (the linked article is not available at the time of this writing).

We could easily reproduce this second bypass on fully updated Windows computers, except on Windows Server 2016. While our own micropatch was not bypassable using Abdelhamid's new trick, Microsoft modified the DLL we wrote the micropatch for (profext.dll), which meant we had to port our patch to the new version of this DLL to protect users who diligently apply Windows updates.

In short, CVE-2021-34484 is again a 0day on supported Windows versions. Somewhat ironically, affected Windows computers whose official support had already ended (Windows 10 v1803, v1809,  and v2004) and have 0patch, did not have this vulnerability reopened.

We ported our micropatch to the latest profext.dll on the following Windows versions: 
  1. Windows 10 v21H2 (32 & 64 bit) updated with March 2022 Updates
  2. Windows 10 v21H1 (32 & 64 bit) updated with March 2022 Updates
  3. Windows 10 v20H2 (32 & 64 bit) updated with March 2022 Updates
  4. Windows 10 v1909 (32 & 64 bit) updated with March 2022 Updates
  5. Windows Server 2019 64 bit updated with March 2022 Updates
 
Since this vulnerability is again a 0day, our micropatches for it became free again and will remain free until Microsoft has issued a correct official fix. To use these micropatches, 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. 

Users who already have 0patch installed do not have to do anything: new micropatches will get applied automatically.


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.

Wednesday, March 16, 2022

0patch Security-Adopts Windows 10 v2004 and v1909 to Keep them Running Securely

 

by Mitja Kolsek, the 0patch Team

 

As time goes on, additional Windows 10 versions go out of official support - we have previously security-adopted Windows 10 v1803 and v1809, and now we're happy to report that we're adding two versions to the list:

  1. Windows 10 v2004: This version stopped receiving security updates from Microsoft in December 2021, but we've since been delivering critical security micropatches for it to keep it running securely. If you're running Windows 10 v2004 in your organization, all you need to do is install 0patch Agent on these computers and register it to an account with PRO or Enterprise subscription.

  2. Windows 10 v1909: Enterprise, Education and IoT Enterprise releases of this Windows 10 version will receive its last security update from Microsoft in May this year (two months from now). At that time we will security-adopt it and start providing critical security micropatches to keep it running securely.

 

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 v1909/v2004 with 0patch will also receive our occasional micropatches for "0day" vulnerabilities in various products.

In order to have our micropatches applied, users will have to have their computers fully updated with the latest official Windows Updates provided by Microsoft: December 2021 updates for v2004, and May 2022 updates for v1909.

We welcome all interested organizations to contact sales@0patch.com for information about pricing, deployment, or setting up a trial.

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

Thursday, March 10, 2022

Micropatches for Two Similar Remote Code Execution Issues (CVE-2022-21971, CVE-2022-21974)

 


 

by Mitja Kolsek, the 0patch Team

 

Twelve days ago, security researcher Axel Souchet published detailed analyses with associated proofs-of-concept for two remotely exploitable vulnerabilities in Windows that were fixed by Microsoft with February Windows Updates. Both vulnerabilities are similar and are caused by an uninitialized pointer that a malicious RTF file can get freed while having an illegal value.

Exploitability of such issues depends on whether the attacker can get the uninitialized value to point to a chosen address and thus control the resulting memory corruption. We don't know if this is possible but following the worst-case assumption principle (and historical track record showing that to be generally possible with sufficient motivation), unexplored memory corruption issues are assumed to allow for a remote code execution.

The two vulnerabilities are:

  1. CVE-2022-21971 - see Axel's POC with analysis
  2. CVE-2022-21974 - see Axel's POC with analysis

While Axel found these vulnerabilities, he was not the only one; both issues were reported to Microsoft by Zesen Ye and Zhiniang Peng with Sangfor, and CVE-2022-21971 also by Jinquan with DBAPPSecurity Lieying Lab. There was some initial uncertainty on whether these CVE IDs really matched Axel's findings, but Zhiniang has confirmed the match.

It was trivial to reproduce both issues by simply enabling Page Heap for WordPad.exe and opening Axel's RTF documents with WordPad. While WordPad requires the user to unblock content in a security warning, opening the same document in Microsoft Word produces no warnings. We preferred using WordPad for our analysis, however, as it is present on Windows by default.

Our analysis of Microsoft's fixes for these issues revealed that, unsurprisingly, they just added pointer initialization to constructor code. The image below shows a diff between vulnerable (left) and fixed constructor (right) in RMSRoamingSecurity.dll., and something similar was done in prauthproviders.dll as well.


 

Our micropatches are logically equivalent to Microsoft's. They were written for the following Windows versions that don't receive official patches from Microsoft:


  1. Windows 10 v1803 updated to May 2021
  2. Windows 10 v1809 updated to May 2021
  3. Windows 10 v2004 updated to December 2021


Note that Windows 7 and Server 2008 R2 are not affected as the vulnerable functionalities do not exist there. 

 

Here is a video showing how 0patch blocks exploitation of these vulnerabilities:


 

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

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

We'd like to thank Axel Souchet for publishing their analyses and providing proofs-of-concept that allowed us to reproduce these vulnerabilities and create micropatches for them. We also encourage security researchers to privately share their analyses with us for micropatching.

Wednesday, March 9, 2022

Micropatches for "SpoolFool" Print Spooler Elevation of Privilege (CVE-2022-21999)



by Mitja Kolsek, the 0patch Team

 

Security researcher Oliver Lyak published a detailed analysis of a local privilege escalation vulnerability in Windows Print Spooler (CVE-2020-1030), which they had previously reported to Microsoft in November 2021, and a fix for which was included three months later with February 2022 Windows Updates. (Thanks to Cliff Featherstone for pointing out we can't do math as we originally stated this was 15 months later.)

Vulnerability CVE-2022-21999, nicknamed "SpoolFool", complements numerous previously found issues in Windows Print Spooler, and like many of those, uses symbolic links to trick the Print Spooler service running with System privileges into doing something with file system that benefits the local attacker.

In this case (see proof-of-concept), the attacker makes the Print Spooler service change permissions of an attacker-chosen folder on the computer such that everyone can create files in it. It does so by creating a printer (any user can do that by default on a Windows workstation) with its own dedicated spooler folder. When Print Spooler service is restarted, it checks every printer's spooler folder to make sure it's there and properly set up - if the folder doesn't exist, the service creates it, and if the folder doesn't allow all users to write to it, it sets everyone-write permissions on it.

Oliver noticed that creating a symbolic link from a printer's spooler folder to some system folder results in Print Spooler service setting such permissions to said system folder, thus allowing the attacker to create arbitrary files there. Having this capability, the attacker can get their own executable launched by some system process.

Microsoft's patch changed the behavior of Print Spooler service such that upon restart, it no longer creates a spooler folder or change its permissions, thus redirecting printers with misconfigured spooler folders to the default spooler folder. Our micropatch does effectively the same.

The micropatch was written for the following Windows versions that don't receive official patches from Microsoft:


  1. Windows 10 v1803 updated to May 2021
  2. Windows 10 v1809 updated to May 2021
  3. Windows 10 v2004 updated to December 2021
  4. Windows 7 updated with ESU year 2, ESU year 1 or updated to January 2020
  5. Windows Server 2008 R2 updated with ESU year 2, ESU year 1 or updated to January 2020


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

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

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

Wednesday, January 12, 2022

Free Micropatches for "RemotePotato0", a "WON'T FIX" Local Privilege Escalation Affecting all Windows Systems


 

by Mitja Kolsek, the 0patch Team

 

Update 1/19/2022: User informed us that our initial micropatch for this issue broke Windows Hello PIN settings (not the login, but creating or editing the PIN). We analyzed the issue and found that our initial test for requestor's permissions was causing the problem in this case. We therefore revoked the initial patches and issued new ones where we check for requestor's permissions using token's TokenIsElevated value

Update 3/17/2022: March 2022 Windows Updates modified rpcss.dll on some Windows versions, so we ported our micropatch to these new versions. This vulnerability was presented to Microsoft employees at the Microsoft BlueHat Israel conference.

Back in April 2021, researcher Antonio Cocomazzi of Sentinel LABS and independent security researcher Andrea Pierini published an article titled Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol. The article described a local privilege escalation vulnerability they had found in Windows and reported to Microsoft, who decided not to fix because "Servers must defend themselves against NTLM relay attacks."

As far as real world goes, many servers do not, in fact, defend themselves against NTLM relay attacks. Since the vulnerability is present on all supported Windows versions as of today (as well as all unsupported versions which we had security-adopted), we decided to fix it ourselves.


The Vulnerability

The vulnerability is comprehensively described in the Sentinel LABS article. It allows a logged-in low-privileged attacker to launch one of several special-purpose applications in the session of any other user who is also currently logged in to the same computer, and make that application send said user's NTLM hash to an IP address chosen by the attacker. Intercepting an NTLM hash from a domain administrator, the attacker can craft their own request for the domain controller pretending to be that administrator and perform some administrative action such as adding themselves to the Domain Administrators group.

To exploit this issue, some higher-privileged user must be logged in to the same Windows computer as the attacker at the same time. This is a relatively exotic situation on Windows workstations, although possible with the "Switch user" feature that keeps one interactive user logged in while another user logs in interactively to the same computer. One could imagine a malicious user asking the administrator to help them resolve some issue by logging in to their workstation via "Switch user", where a script running in attacker's session would autonomously perform the attack.

A much more interesting target are Windows servers, especially terminal servers where multiple users, both unprivileged and administrators, have simultaneous user sessions. There, any remotely logged-in user could attack any other user that is currently also logged in, and do so without social engineering or any assistance by the victim.

Microsoft decided not to fix this issue as their position is that NTLM relaying should be prevented through NTLM configuration or by not using NTLM anymore. Such changes have potential to break something, so companies are understandably a bit reluctant to implement them in their production environments.

 

Patching This Issue

To fix a vulnerability, one must first understand it, and the functionality within which it resides. This immediately brings us to the question: Why does Windows allow a low-privileged user to cause anything to get launched at all in a session other than their own? Unfortunately, we failed to find the answer or even come up with some hypothetical reason. A feature like this would immediately look suspect to any security researcher, and it's not a surprise that someone had looked at it and found it to be exploitable.

It would be easy for us to completely disable this strange functionality but just in case it's being used for some reason, we decided to only block it in case a non-privileged user is trying to launch a process in another session. We wanted to allow privileged users such as administrators or Local System to use this mysterious feature if they wanted, but prevent normal users from doing so.

Our patch was therefore placed in the execution flow of rpcss.dll where requestor's token, requestor's session ID and target session ID are known, and does the following:

  1. If requestor's session ID is the same as target session ID, we do not interfere. (If the user wants to launch processes in their own session, let them do it.)
  2. Else, if requestor's token allows for some privileged operation, we do not interfere. (Specifically, if requestor's token has a non-zero TokenIsElevated value, we consider the requestor as privileged, and do not interfere.)
  3. Else, we block the operation.


Source code of our micropatch:



MODULE_PATH "..\Affected_Modules\rpcss.dll_10.0.19041.1387_Win10-21H1_64-bit_u202112\rpcss.dll"
PATCH_ID 749
PATCH_FORMAT_VER 2
VULN_ID 7190
PLATFORM win64

patchlet_start
  PATCHLET_ID 1
  PATCHLET_TYPE 2
  PATCHLET_OFFSET 0x115b8
  N_ORIGINALBYTES 5
  JUMPOVERBYTES 0
  PIT rpcss.dll!0xec38,Advapi32.dll!ImpersonateLoggedOnUser,Advapi32.dll!RevertToSelf,Advapi32.dll!RegOpenKeyExW,Advapi32.dll!RegCloseKey,rpcss.dll!0x11560
 
  code_start
    
    push r12               ; store registry values
    push r13
    push r9
    sub rsp, 8             ; align stack
 
    mov r13, [rbp-68h]     ; this - contains current session token
    mov rcx, [r13+48h]     ; get current session token
    sub rsp, 20h           ; home space
    call PIT_0xec38        ; call GetSessionId2, returns session id
    add rsp, 20h           ; restore stack pointer
    mov r12, rax           ; store session id
    
    mov rcx, [rbp-58h]     ; target session token
    sub rsp, 20h           ; home space
    call PIT_0xec38        ; call GetSessionId2, returns session id
    add rsp, 20h           ; restore stack pointer
    cmp rax, r12           ; compare both session ids
                           ; equal -> continue normal code flow
                           ; not equal -> check if current session has elevated privileges
    je CONTINUE
    
    mov rcx, [r13+48h]     ; current session token
    sub rsp, 20h           ; home space
    call PIT_ImpersonateLoggedOnUser  ; the user is represented by token handle
                           ; If the function succeeds, the return value is nonzero
    add rsp, 20h           ; restore stack pointer
    cmp eax, 0             ; check return value
    je CONTINUE
    
    mov r12, 0             ; r12 stores a value that decides if requestor has
                           ; elevated privileges
                           ; 0 - not elevated
                           ; 1 - elevated
    mov rcx, 0FFFFFFFF80000002h ; handle to HKLM registry, hKey
    call VAR
        dw __utf16__('SOFTWARE'), 0
  VAR:
    pop rdx                ; rdx points to string "SOFTWARE", lpSubKey
    mov r8, 0              ; ulOptions - must be 0
    mov r9, 4              ; samDesired - write access desired
    sub rsp, 30h           ; home space + 10h to store vars on stack
    mov qword[rsp+28h], 0  ; resulting handle is at rsp+28h
    lea rax, [rsp+28h]     ; get address of handle
    mov [rsp+20h], rax     ; phkResult
    call PIT_RegOpenKeyExW ; Opens the specified registry key
    mov r13, [rsp+28h]     ; store return value
    add rsp, 30h           ; restore stack pointer
    cmp eax, 0             ; If the call succeeded, return value is ERROR_SUCCESS(0).
    jne REVERT             ; jmp if function fails
    
    mov rcx, r13           ; hKey
    sub rsp, 20h           ; home space
    call PIT_RegCloseKey   ; Close the handle of registry key
    add rsp, 20h           ; restore stack pointer
    mov r12, 1             ; elevated privileges
    
  REVERT:
    sub rsp, 20h           ; home space
    call PIT_RevertToSelf  ; RevertToSelf terminates previous impersonation
    add rsp, 20h           ; restore stack pointer
    cmp r12, 1             ; check if current user has elevated privileges
    je CONTINUE            ; jmp if yes
    
    add rsp, 8             ; restore stack to original state before patch
    pop r9
    pop r13
    pop r12
    jmp PIT_0x11560        ; skip to end of the function, blocking the attack
    
  CONTINUE:
    add rsp, 8             ; restore stack to original state before patch
    pop r9
    pop r13
    pop r12
    
  code_end
 
patchlet_end

 

Here is a video showing how the micropatch blocks exploitation of this vulnerability:



Micropatch Availability

This micropatch was written for: 

  1. Windows 10 v21H1 32&64 bit updated with December 2021 or January 2022 Updates
  2. Windows 10 v20H2 32&64 bit updated with December 2021 or January 2022 Updates
  3. Windows 10 v2004 32&64 bit updated with December 2021 or January 2022 Updates
  4. Windows 10 v1909 32&64 bit updated with December 2021 or January 2022 Updates
  5. Windows 10 v1903 32&64 bit updated with December 2021 or January 2022 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 7 32&64 bit updated with January 2020 Updates (no ESU)
  9. Windows 7 32&64 bit updated with January 2021 Updates (year 1 of ESU)
  10. Windows 7 32&64 bit updated with December 2021 or January 2022 Updates (year 2 of ESU)
  11. Windows Server 2019 64 bit updated with December 2021 or January 2022 Updates
  12. Windows Server 2016 64 bit updated with December 2021 or January 2022 Updates
  13. Windows Server 2012 R2 64 bit updated with December 2021 or January 2022 Updates
  14. Windows Server 2012 64 bit updated with December 2021 or January 2022 Updates
  15. Windows Server 2008 R2 64 bit updated with January 2020 Updates (no ESU)
  16. Windows Server 2008 R2 64 bit updated with January 2021 Updates (year 1 of ESU)
  17. Windows Server 2008 R2 64 bit updated with January 2022 Updates (year 2 of ESU)
  18. Windows Server 2008 64 bit updated with January 2020 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 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 Antonio Cocomazzi and Andrea Pierini for finding this issue and sharing details, which allowed us to create a micropatch and protect our users.


0patch and Microsoft Extended Security Updates

 
If you're using Windows 7 or Windows Server 2008 R2 with Extended Security Updates (ESU), you have just received the last Windows Updates for the year and are facing paying twice as much as last year to continue receiving Microsoft's official security fixes.

0patch is a much less expensive and less intrusive alternative to ESU. We started by security-adopting Windows 7 and Server 2008 R2 in 2020 when official support for these platforms ended, and many users installed 0patch to keep their systems running securely. Almost all of them are still running today, and you can join them by using 0patch on top of ESU updates you've received up to this point. 
 
See  how 0patch compares to Extended Security Updates and contact sales@0patch.com for details or a trial.


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

 

 

Thursday, December 23, 2021

Micropatching "ms-officecmd" Remote Code Execution (CVE-2021-43905)

 


by Mitja Kolsek, the 0patch Team

 

Update 1/5/2022: Microsoft changed their mind and issued a CVE ID for this vulnerability: CVE-2021-43905. The latest version of LocalBridge also no longer recognizes the ms-officecmd: URI scheme.

Earlier this month, security company Positive Security published a detailed analysis of a critical vulnerability they had discovered in the handling of the "ms-officecmd" URL handler. In short, this vulnerability allowed a remote attacker to execute arbitrary code on user's computer when user visited a malicious web page with a browser or opened a link provided to them in documents or messaging applications.

Positive Security have responsibly reported this bug to Microsoft, who fixed it without assigning it a CVE ID, reportedly because "Changes to websites, downloads through Defender, or through the Store normally do not get a CVE attached in the same way. In this case the fix did not go out through Windows Update.

Having a fix delivered though an alternative mechanism instead of Windows Update is not unprecedented in Windows, but can depend on assumptions that may not always be true. In this case, the fix was delivered through Windows Store - but only if the AppX Deployment Service was running. This service (AppXSVC) is enabled on Windows 10 by default and gets started when needed, but a quick Google search finds many people asking how to disable it, some presumably doing so. In addition, there is no need to have Windows Store working on users' computers in a typical enterprise environment, and in fact Microsoft provides instructions for blocking such access.

The situation is therefore such that a remote code execution vulnerability with no CVE ID assigned and official fix issued may have remained unfixed on an unknown number of computers worldwide. To make things worse, the DLL that was fixed (AppBridge.dll) has no version information, making it hard for anyone to determine whether their computer is vulnerable or not.

 

No version information for AppBridge.dll

 

The Vulnerability

The vulnerability is nicely described in Positive Security's blog post, so let's just focus on the crux here: various Windows applications such as Office, Teams or Skype register the "ms-officecmd" URL handler, which makes it possible to launch these applications by simply opening a URL provided in a hyperlink or visiting a web page. This handler parses the entire URL to determine which application is to be launched, and which file it should open.

This filename value in an "ms-officecmd" URL is problematic because it gets passed on to the launched application in form of a command-line argument. An application may, however, happily accept various additional arguments, and the vulnerability in question allows these to be sneaked in through the filename value. Teams, for example, is an Electron-based application and accepts the --gpu-launcher argument that launches any other app - as specified by the attacker.

Consequently, visiting a malicious web page while having Teams installed could launch malware on your computer. Whether you would have to okay a not-too-security-alert-looking dialog or not depended on the browser.


Microsoft's Fix

Microsoft addressed this issue in two places:

  1. When the filename value points to a file (instead of a URL on the web), the new code tries to open such file locally and only continues with launching the application if that succeeds. This blocks maliciously injected arguments because a file that would match the malicious filename would not be present on user's computer and therefore couldn't be opened. (Side note: a malicious file could also be stored on a remote share and actually contain various unusual characters, so we're not entirely sure about the completeness of this approach.)
  2. When the application is launched, the supplied filename value is enclosed in double quotes to force it to be parsed as a single argument.

 

After this fix was issued, Positive Security researchers found it to be incomplete, still allowing for argument injection with web-based filenames, such as launching Word with the /q argument like this:

"filename": "https://example.com/\" /q"

Those familiar with injection attacks will notice that even if the string is enclosed in double quotes, the double quote that is already in the string will terminate the starting quote and allow for the introduction of another argument. Classic injection attack.

Fortunately, at least Teams won't launch with a web-based URL argument like this but since many Office applications can be launched via "ms-officecmd" URL, the remaining exploitability of this issue can only be assessed with extensive analysis.

 

Our Micropatch

Our approach at this issue was more classic in terms of preventing injections. We replicated Microsoft's 2nd code change, enclosing the entire filename value in double quotes before it gets sent to ShellExecute, but we also added a check for existence of double quotes in the filename value and flat out refuse to launch the application if any are found. A double quote cannot be part of a Windows file name (it's one of the forbidden characters), and if someone wants to use double quotes in a web-based URL, they should encode them as %22.

Our patch was written for 32-bit and 64-bit AppBridge.dll that was delivered to Windows machines through Windows Store in October 2020. This is the last vulnerable version, and was subsequently replaced with a fixed version in June 2021. Our patch will therefore only get applied if you had Windows Store enabled in October 2020, and disabled it some time before June 2021. We expect some users may have older, or much older, versions of AppBridge.dll installed due to having disabled Windows Store earlier. In absence of AppBridge.dll version information, we can only recommend locally testing your exploitability by copy-pasting the following URL to your web browser on a machine with Microsoft Teams installed, and seeing if a calculator gets launched:


ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c calc && \""
   }
}


Here is a video showing how 0patch prevents the above URL from launching calculator.



Micropatch Availability

This micropatch requires a 0patch PRO or Enterprise license as it cannot be considered a 0day anymore. To determine if it applies to your computer at all, you can install 0patch Agent with a free account and see if the patch appears under relevant patches.

If you're not sure whether you're vulnerable or not, try to locate AppBridge.dll on your computer: it should be in a folder like C:\Program Files\WindowsApps\Microsoft.MicrosoftOfficeHub_[version]_x64__8wekyb3d8bbwe. (Note that the folder is only accessible to admins so running a full disk search as a non-admin user won't work.)

Once you've located the file, contact us at sales@0patch.com and provide the exact file size and modification date of file AppBridge.dll and the name of the folder you found it in. For the record, the vulnerable AppBridge.dll on our test systems was in a folder version 18.2008.12711.0.


We'd like to thank researchers from Positive Security for finding this issue and sharing details, which allowed us to create a micropatch and protect our users. We'd also like to thank Will Dormann for additional analysis of this issue.

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