.Details are scarce so far, but Microsoft is warning Office users about a bug that’s dubbed CVE-2021-40444, and described as Microsoft MSHTML Remote Code Execution Vulnerability.
The bug doesn’t have a patch yet, so it’s what’s known as a zero-day, shorthand for “the Good Guys were zero days ahead of the Bad Guys with a patch for this vulnerability.”
In other words: the crooks got there first.
As far as we can tell, the treachery works like this:
- You open a booby-trapped Office file from the internet, either via an email attachment or by downloading a document from a criminal-controlled web link.
- The document includes an ActiveX control (embedded add-on code) that ought not to have unrestricted access to your computer.
- The ActiveX code activates the Windows MSHTML component, used for viewing web pages, exploits a bug in it to give itself the same level of control that you yourself would have right from the Windows desktop, and uses it to implant malware of the attacker’s choice.
MSHTML isn’t a full-on browser, like Internet Explorer or Edge, but is a part of the operating system that can be used to create browsers or browser-like applications that need or want to display HTML files.
Even though HTML is most closely associated with web browsing, many apps other than browsers find it useful to be able to render and display web content, for example as a convenient and good-looking way to present documentation and help files, or to let users fill in and submit support tickets.
This “stripped down minibrowser” concept can be found not only on Windows but also on Google’s Android and Apple’s iOS, where the components Blink and WebKit respectively provide the same sort of functionality as MSHTML on Microsoft platforms. Mozilla products such as Firefox and Thunderbird are based on a similar idea, known as Gecko. On iOS, interestingly, Apple not only uses WebKit as the core of its own browser, Safari, but also mandates the use of WebKit in browsers or browser-like apps from all other vendors. That’s why Firefox on iOS is the only version of that product that doesn’t include Gecko – it has no choice but to use WebKit instead.
HTML isn’t just for browsing
What this means is that HTML rendering bugs don’t just affect your browser and your browsing activity, and therefore there may be many different ways than just sending you a dodgy web link for cybercriminals to poke a virtual stick into buggy web rendering code, and thereby to probe for exploits.
Even if there’s a bug that they can’t quite control closely enough to take over your browser of choice, they may be able to find other applications in which the vulnerability can not only be used to crash the app, but also to exploit it in order to grab control from it and implant malware.
That’s what CVE-2021-40444 seems to do, with the attack being delivered via Office files loaded into Word, Excel and so on, rather than by web pages viewed directly in your browser.
What to do?
- Avoid opening documents you weren’t expecting. Don’t be tempted to look at content just because an email or a document happens to align with your interests, your line of work, or your current research. That doesn’t prove that the sender actually knows you, or that they can be trusted in any way – that information is probably publicly available via your work website or your own social media posts.
- Don’t be tempted to break out of Office Protected View. By default, Office documents received via the internet (whether by email or web) open in a way that prevents active content such as Visual Basic macros and ActiveX controls from running. If you see a yellow bar at the top of the page, warning you that potentially dangerous parts of the document were not activated, resist clicking the
[Enable Editing]button, especially if the text of the document itself “advises” you to!
- Consider enforcing Protected View permanently for all external content. System administrators can enforce network-wide settings that prevent anyone from using the
[Enable Editing]option to escape from Protected View in Office. Ideally, you should never need to trust so-called active content in external documents, and you sidestep a wide range of attacks if you prevent this happening altogether.
- Disable ActiveX controls that use the MSHTML web renderer. Sysadmins can enforce this with network-wide registry settings that stops ActiveX controls that arrive in new documents from working at all, regardless of whether the document is opened in Protected View or not. This workaround specifically prevents the CVE-2021-40444 vulnerability from being exploited.
- Disable the use of ActiveX in Office. If you don’t need ActiveX in Office at all, this helps not only to stop this attack but also to block the abuse of ActiveX in by other Office-borne threats.
- Keep your eyes peeled for a patch from Microsoft. Next Tuesday (2021-09-14) is the September 2021 Patch Tuesday date; let’s hope Microsoft gets a full-blown fix ready by or before then!
GROUP POLICY SETTINGS AND REGISTRY ENTRIES YOU MAY FIND USEFUL
1. To neutralise ActiveX inside Internet Explorer (of which MSHTML forms the core, as explained above), follow the registry modification instructions in Microsoft’s own Security Update Guide for CVE-2021.40444.
2. In the Windows Group Policy Editor, look for the settings listed below.
You can use the
gpedit.msc app to edit the local Group Policy on a standalone computer, or the
Group Policy Management Console app if you are managing a Windows domain.
Note that the VBA settings below (VBA is short for Visual Basic for Applications, also known as “Office macro code”) don’t directly help with the CVE-2021-40444 zero-day hole, which relies on ActiveX, but are worth considering as an additional part of your Microsoft Office security posture.
User Configuration > Administrative Templates > Microsoft Office 2016 > Security Settings > Disable All ActiveX <--if you don't need ActiveX Disable VBA for Office Applications <--if you can do without document macros User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center Block macros from running in Office files from the internet User Configuration > Administrative Templates > Microsoft Excel 2016 > Excel Options > Security > Trust Center Block macros from running in Office files from the internet User Configuration > Administrative Templates > Microsoft Powerpoint 2016 > Powerpoint Options > Security > Trust Center Block macros from running in Office files from the internet User Configuration > Administrative Templates > Microsoft Word 2016 > Word Options > Security > Trust Center Block macros from running in Office files from the internet
To administer the Office settings above via the Group Policy editor, you will need to install the Administrative Templates for Office 365, Office 2019 and Office 2016 files from Microsoft, which aren’t installed by default on Windows desktops or servers, even if you have already installed Office itself. Download the above file and install the contents into
3. If you want to turn on the Disable All Active X option on your own computer directly without using
gpedit, and you are comfortable with editing the Windows registry yourself, you can create the following entry:
HKEY_CURRENT_USER > SOFTWARE > Policies > Microsoft > <--these keys should already exist office > commmon > security > <--use "New - Key" to create these nested subkeys [DWORD] disableallactivex = 1 <--finally, use "New - DWORD (32-bit) Value"
CMD.EXE (a regular command prompt window), you can use these commands to check and set the relevant registry entry:
> reg query HKCUSOFTWAREPoliciesMicrosoftofficecommonsecurity ^ /v disableallactivex ERROR: The system was unable to find the specified registry key or value. > reg add HKCUSOFTWAREPoliciesMicrosoftofficecommonsecurity ^ /v disableallactivex ^ /t REG_DWORD /d 1 The operation completed successfully. > reg query HKCUSOFTWAREPoliciesMicrosoftofficecommonsecurity ^ /v disableallactivex HKEY_CURRENT_USERSOFTWAREPoliciesMicrosoftofficecommonsecurity disableallactivex REG_DWORD 0x1