On Saturday, April 26 Microsoft announced that Internet Explorer version 6 until version 11 is under potential risk against drive-by attacks from malicious websites, regardless of the underlying Microsoft operating system and the associated memory protection features integrated with the operating system. Microsoft has assigned CVE-2014-1776 to this unknown use-after-free vulnerability, which in the worst case could allow remote code execution if a user views a specially crafted website. If an attacker successfully exploits this vulnerability, s/he will gain the same rights and privileges as the current user (once again, activated User Account Control [UAC] helps keeping privileges of the user low).
The recommended mitigating controls from Microsoft, especially unregistering the VGX.DLL library has led to the misunderstanding, that many people thought the vulnerability is located in the VGX.DLL library. That is wrong. Instead, the vulnerability is located in mshtml.dll, mshtml.tlb, Microsoft-windows-ie-htmlrendering.ptxml, and Wow64_microsoft-windows-ie-htmlrendering.ptxml and therefore unregistering of the above library does not globally mitigate the vulnerability. It only mitigates a specific attack vector where Vector Markup Language (VML) is being used during the attack.
What is VML?
VML is almost the same as Scalable Vector Graphics (SVG) or Precision Graphics Markup Language (PGML): these are markup languages for vector graphics. These vector formats are based on the Extensible Markup Language (XML) and support in addition to the pixel graphics in JPEG, Graphics Interchange Format (GIF) or Portable Network Graphics (PNG) vector based web objects.
Microsoft states that Vector Markup Language is obsolete in/since Internet Explorer 10. http://msdn.microsoft.com/en-us/library/ie/hh801223(v=vs.85).aspx
But VML remains available in Internet Explorer 10 as a legacy feature (through the so-called “document modes” 5,7,8 and 9). The document mode defines how Internet Explorer renders a website. These modes allow you to choose between the newest standards, such as HTML5, Cascading Style Sheets (CSS3) and SVG etc., or support for certain behaviors commonly used by older browsers.
What has the VGX.DLL library to do with all this?
The VGX.DLL library is the library responsible for rendering embedded VML objects in the web. An interesting fact is that in the past the VGX.DLL library showed vulnerabilities over and over again or was closely related to other vulnerabilities. The fact that VML is an obsolete language makes it necessary to reflect on permanently unregistering or even deleting this VGX.DLL vulnerable library. What implications does this mitigation control have? Applications that render VML based web contents will no longer be able to do so. To find out if you are affected this control needs to be tested extensively. What must be emphasized is that the latest browsers do not support these obsolete features by default.
|
CVE |
CVSS |
|
CVE-2014-1776 |
CVSS Severity: 10.0 HIGH |
|
CVE-2014-0322 |
CVSS Severity: 9.3 HIGH |
|
CVE-2013-0030 |
CVSS Severity: 9.3 HIGH |
|
CVE-2012-0172 |
CVSS Severity: 9.3 HIGH |
|
CVE-2012-0155 |
CVSS Severity: 9.3 HIGH |
|
CVE-2011-1266 |
CVSS Severity: 9.3 HIGH |
Tabelle 1: A small overview of the last 3 years in which the VGX.DLL library was involved
Exploitation of CVE-2014-1776
Different exploits are in the field considering them all here in this blogpost is not possible. The most common attack in the field involves a malicious Flash SWF file. The embedded actionscript code in this file serves multiple purposes during the attack.
First preparation of the heap by spraying it with vector objects, followed by allocating another vector which contains a sound object. This is a well-known exploitation technique to successfully bypass Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). After all this, RC4 encrypted JavaScript code is called to actually trigger the use-after-free vulnerability.
A more detailed explanation of the exploit can be found here:
http://www.cyphort.com/blog/dig-deeper-ie-vulnerability-cve-2014-1776-exploit/
Mitigating Controls
Since the patch is available it is highly recommended to install it. If this is not possible, due to operational reasons /corporate environments with hundreds of thousands of computers, proceed as follows:
1. Install the Enhanced Mitigation Experience Toolkit (EMET) in addition to memory protection mechanisms provided by the operating system to ensure the integrity of system memory. If you (still) don´t know about EMET, see here more about this security software tool, which in our opinion should be installed on each windows box.
https://www.ernw.de/download/emet/emet_walkthrough_v.1.0_signed.pdf
Note: Different security incidents have shown that EMET was able to break the exploit logic and therefore it could not be executed successfully. Until the effective protection of EMET is proven wrong, it is currently the only useful control against the current and maybe also future vulnerabilities.
The following parameters have particularly huge functionality impact in the sense that activating them will lead in to usability problems. To provide a better understanding of these, they are listed and discussed in the following:
2. On x64-based systems: Enable the Enhanced Protected Mode (EPM) for Internet Explorer 10/11.
In Internet Explorer 11 on Windows 8.1, the separate option “Enable 64-bit processes for EPM” must also be enabled in addition to the option “Enable Enhanced Protected Mode”.
By activating Enhanced Protected Mode all Internet Explorer processes run in 64-bit mode and therefore any incompatible add-ons (32-bit add-ons) are disabled. Be aware of: This will affect the user’s browsing experience significantly and makes web sites inaccessible that rely on these add-ons.
3. Unregister the VGX.DLL library.
Websites with these obsolete vectors graphic cannot be called, but what we can say is that we see these graphics rarely in or daily business.
“%SystemRoot%\System32\regsvr32.exe” -u “%CommonProgramFiles%\Microsoft Shared\VGX\vgx.dll”
“%SystemRoot%\System32\regsvr32.exe” -u “%CommonProgramFiles(x86)%\Microsoft Shared\VGX\vgx.dll”
As stated above this does_not_cure the vulnerability itself but only mitigate a certain class of exploits. Unregistering this library will to problems processing VML based web content.
4. Block ActiveX Controls
Users often choose to install software such as ActiveX controls that are malicious and pose a threat to the security of an organization. This software also can significantly affect the privacy of a business. To prevent users from installing unauthorized ActiveX controls, a number of settings can be configured but in our opinion the only one what makes sense in a corporate environment is the following:
Deny all add-ons unless specifically allowed in the Add-on List:
“Enabling” this parameter allows to control the use of ActiveX controls. If enabled without further listing allowed add-ons by means of their respective CLSIDs, essentially disables any use of add-ons. Thus listing CLSIDs allows for a fine-grained control of add-ons as a whole.
5. Block Active Scripting
Deactivating Active Scripting (per Internet Explorer zone) can be used to protect against a discovered vulnerability that does not yet have an update or in response to critical security scripting attacks. Blocking Active Scripting will affect whole Internet Explorer zone.
Note: That blocking Active Scripting will lead to a major decrease in functionality, since nearly all websites need scripts. Even though certainly desirable from a security point of view, disabling this is regarded impossible in a volatile corporate environment.
So you have to think about it carefully!!! See also our 2010 newsletter on the topic:
https://www.ernw.de/wp-content/uploads/ERNW_Newsletter_31_Secure_IE8_Configuration_en.pdf
I hope I could contribute to a better understanding of the vulnerability, thanks! for reading.
Have a good one,
Dominik Phillips.