Microsoft Internet Explorer Memory Corruption Vulnerabilities
Remote code execution vulnerabilities exist when Internet Explorer improperly accesses objects in memory.

The vulnerabilities could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user.

An attacker who successfully exploited the vulnerabilities could gain the same user rights as the current user.
If the current user is logged on with administrative user rights, the attacker could take control of an affected system.

An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
An attacker could host a specially crafted website that is designed to exploit the vulnerabilities through Internet Explorer, and then convince a user to view the website.

The attacker could also take advantage of compromised websites, or websites that accept or host user-provided content or advertisements, by adding specially crafted content that could exploit the vulnerabilities.
In all cases, however, an attacker would have no way to force users to view the attacker-controlled content.
Instead, an attacker would have to convince users to take action, typically by an enticement in an email or Instant Messenger message, or by getting them to open an attachment sent through email.

The update addresses the vulnerabilities by modifying how Internet Explorer handles objects in memory.
The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list:

Vulnerability title

CVE number

Publicly disclosed

Exploited

Internet Explorer Memory Corruption Vulnerability

CVE-2016-0199

No

No

Internet Explorer Memory Corruption Vulnerability

CVE-2016-0200

No

No

Internet Explorer Memory Corruption Vulnerability

CVE-2016-3211

No

No

Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds
Microsoft has not identified any workarounds for this vulnerability.

FAQ
I am running Internet Explorer on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2.

Does this mitigate these vulnerabilities?
 Yes.

By default, Internet Explorer on Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 runs in a restricted mode that is known as Enhanced Security Configuration.

Enhanced Security Configuration is a group of preconfigured settings in Internet Explorer that can reduce the likelihood of a user or administrator downloading and running specially crafted web content on a server.

This is a mitigating factor for websites that you have not added to the Internet Explorer Trusted sites zone.
Can EMET help mitigate attacks that attempt to exploit these vulnerabilities? Yes.

The Enhanced Mitigation Experience Toolkit (EMET) enables users to manage security mitigation technologies that help make it more difficult for attackers to exploit memory corruption vulnerabilities in a given piece of software.

EMET can help mitigate attacks that attempt to exploit these vulnerabilities in Internet Explorer on systems where EMET is installed and configured to work with Internet Explorer.
For more information about EMET, see the Enhanced Mitigation Experience Toolkit.

Multiple Scripting Engine Memory Corruption Vulnerabilities
Multiple remote code execution vulnerabilities exist in the way that the JScript 9, JScript, and VBScript engines render when handling objects in memory in Internet Explorer.

The vulnerabilities could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user.

An attacker who successfully exploited the vulnerabilities could gain the same user rights as the current user.
If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerabilities could take control of an affected system.

An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerabilities through Internet Explorer and then convince a user to view the website.

An attacker could also embed an ActiveX control marked “safe for initialization” in an application or Microsoft Office document that hosts the IE rendering engine.

The attacker could also take advantage of compromised websites, and websites that accept or host user-provided content or advertisements.

These websites could contain specially crafted content that could exploit the vulnerabilities.

The update addresses the vulnerabilities by modifying how the JScript 9, JScript, and VBScript scripting engines handle objects in memory.
The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list:

Vulnerability title

CVE number

Publicly disclosed

Exploited

Scripting Engine Memory Corruption Vulnerability

CVE-2016-3202

No

No

Scripting Engine Memory Corruption Vulnerability

CVE-2016-3205

No

No

Scripting Engine Memory Corruption Vulnerability

CVE-2016-3206

No

No

Scripting Engine Memory Corruption Vulnerability

CVE-2016-3207

No

No

Scripting Engine Memory Corruption Vulnerability

CVE-2016-3210

No

No

Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds
The following workaround may be helpful in your situation:
Restrict access to VBScript.dll and JScript.dll
For 32-bit systems, enter the following command at an administrative command prompt:

takeown /f %windir%\system32\vbscript.dll
cacls %windir%\system32\vbscript.dll /E /P everyone:N
cacls %windir%\system32\jscript.dll /E /P everyone:N

For 64-bit systems, enter the following command at an administrative command prompt:

takeown /f %windir%\syswow64\vbscript.dll
cacls %windir%\syswow64\vbscript.dll /E /P everyone:N
cacls %windir%\syswow64\jscript.dll /E /P everyone:N

Impact of Workaround. Websites that use VBScript or JScript may not work properly.
How to undo the workaround.
For 32-bit systems, enter the following command at an administrative command prompt:

cacls %windir%\system32\vbscript.dll /E /R everyone
cacls %windir%\system32\jscript.dll /E /R everyone

For 64-bit systems, enter the following command at an administrative command prompt:

cacls %windir%\syswow64\vbscript.dll /E /R everyone
cacls %windir%\syswow64\jscript.dll /E /R everyone

Internet Explorer XSS Filter Vulnerability – CVE-2016-3212
A remote code execution vulnerability exists when the Internet Explorer XSS Filter does not properly validate JavaScript under specific conditions.

An attacker who exploited the vulnerability could run arbitrary code with medium-integrity level privileges (the permissions of the current user).
In a web-based attack scenario, an attacker could host a website in an attempt to exploit this vulnerability.
In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could exploit the vulnerability.
However, in all cases an attacker would have no way to force users to view the attacker-controlled content.
Instead, an attacker would have to convince users to take action.

For example, an attacker could trick users into clicking a link that takes the user to the attacker’s site.

The update addresses the vulnerability by fixing how the Internet Explorer XSS Filter validates JavaScript.
The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list:

Vulnerability title

CVE number

Publicly disclosed

Exploited

Internet Explorer XSS Filter Vulnerability

CVE-2016-3212

No

No

Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds
Microsoft has not identified any workarounds for this vulnerability.

WPAD Elevation of Privilege Vulnerability – CVE-2016-3213
An elevation of privilege vulnerability exists in Microsoft Windows when the Web Proxy Auto Discovery (WPAD) protocol falls back to a vulnerable proxy discovery process.

An attacker who successfully exploited this vulnerability could bypass security and gain elevated privileges on a targeted system.
To exploit the vulnerability, an attacker could respond to NetBIOS name requests for WPAD.

The update addresses the vulnerability by correcting how Windows handles proxy discovery.
The following table contains links to the standard entry for each vulnerability in the Common Vulnerabilities and Exposures list:

Vulnerability Title

CVE number

Publicly disclosed

Exploited

WPAD Elevation of Privilege Vulnerability

CVE-2016-3213

No

No

Mitigating Factors
Microsoft has not identified any mitigating factors for this vulnerability.

Workarounds
The following workarounds may be helpful in your situation.
Disable WINS/NetBT name resolution
Open Network Connections.
Click the Local Area Connection to be statically configured, and then from the File menu, click Properties.
In the list of components, click Internet Protocol (TCP/IP), and then click Properties.
Click Advanced, click the WINS tab, and then click Disable NetBIOS over TCP/IP.
Optionally, you can select the Use NetBIOS setting on the DHCP server if you are using a DHCP server that can selectively enable and disable NetBIOS configuration through DHCP option types.

Stop WPAD using a host file entry
Open the host file located at following location as an administrator: %systemdrive%\Windows\System32\Drivers\etc\hosts
Create the following entry for WPAD in the host file: wpad 255.255.255.255

Impact of workaround. Autoproxy discovery will not work, and for this reason, some applications, such as Internet Explorer, will not be able to load websites properly.
How to undo the workaround. 
Open the host file located at following location as an administrator: %systemdrive%\Windows\System32\Drivers\etc\hosts
Remove the following entry for WPAD in the host file: wpad 255.255.255.255

Leave a Reply