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:
- 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.)
- 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.
