There is an in-the-wild exploit for Microsoft Office. A patch has been released. This exploit has turned up on Virtus Total today.
A remote code execution vulnerability exists in Microsoft Office software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
Exploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Office software. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.
We’ve had this issue on a Windows 2012 Terminal Server. When users click on any type of hyperlink in Outlook (or any other Microsoft product), it gives this error.
This issue is quite interesting. It our case, it has been caused by removing Chrome from the system. But it did not uninstall properly, leaving un-removed registry keys all over the place.
What happens is, when Chrome is installed, it uses a class handler called ChromeHTML. When you click a link, Outlook looks for this class in the registry. If Chrome has not been removed correctly, you will get error above.
The method of fixing this would be to change the .html class under each HKEY_CURRENT_USER, but this is a headache. The better way is to copy htmlfile class, delete the old ChromeHTML class, and reimport htmlfile class as ChromeHTML. This sets ChromeHTML as Internet Explorer, fixing the issue for everyone.
The steps to fix this are as follows:
Delete the ChromeHTML key from HKEY_LOCAL_MACHINESOFTWAREClassesChromeHTML
Export the HKEY_LOCAL_MACHINESOFTWAREClasseshtmlfile key to your desktop, call it reg.reg
Open the reg.reg file in notepad and do a word replace of htmlfile to ChromeHTML
Save the notepad file and exit
Run the registry file which will import the new key
Once users close Outlook and other Microsoft Office programs, the problem will be resolved.
We have a shared environment which we have had issues with lately when customers on slow connections have input lag when using Microsoft Office 2013 applications, specifically, Word.
After much research and testing, we found this issue was to do with Hardware Acceleration that is enabled by default within Office 2013. This is great if you are on a normal desktop/laptop, but not so good on Terminal Server/Remote Desktop Services.
To disable this in word, do the following:
Click File > Options
Scroll down to Display
Tick Disable hardware graphics acceleration
For Group Policy, you need to have the following settings set: