Microsoft issued a security advisory on Friday for a vulnerability in all supported versions of Windows.
The vulnerability exists due to the way MHTML interprets MIME-formatted requests for content blocks within a document. It is possible under certain conditions for this vulnerability to allow an attacker to inject a client-side script in the response of a Web request run in the context of the victim’s Internet Explorer. The script could spoof content, disclose information, or take any action that the user could take on the affected Web site on behalf of the targeted user.
At present there is publicly available exploit code. So while not attacks have been seen in the wild, that is just a matter of time.
Through Microsoft’s Active Protections Program, antimalware venders are able quickly provide protects against these sorts of attacks.
One of the things I like is getting the advisory from Zscaler, a SaaS web security vender. Their bulletin is a tight writeup of the issue advises that protections are in place, and additionally lets you know that Zscaler has reviewed the logs of previous traffic to see if any attacks had occurred already.
My other venders could take a lesson from this. I don’t have the slightest idea what virus definition signature revision needs to be in place for my other products.
While waiting for a patch, and trying to learn if you have any sort of protection from the existing expenditures in security, Microsoft has provided fixit utility to lockdown the MHTML protocol. Generally this needs to be reversed before applying a patch. Check the next security bulletin for MHTML to see if reversing this is needed.
For enterprises, you need to change the registry keys documented in the 2501696 advisory. This can be done through many methods. Notageek.it does a good writeup (in I’m guessing Italian) of how to do it via Group Policy.
Restricting the MHTML protocol will prevent the launch of script in all zones within an MHTML document. Any application that uses MHTML will be affected by this workaround. Script in standard HTML files is not affected by this workaround.