Microsoft Security Bulletin MS14-046 - Important

Published: August 12, 2014 | Updated: September 19, 2014

Version: 1.2

This security update resolves a privately reported vulnerability in Microsoft .NET Framework. The vulnerability could allow security feature bypass if a user visits a specially crafted website. In a web-browsing attack scenario, an attacker who successfully exploited this vulnerability could bypass the Address Space Layout Randomization (ASLR) security feature, which helps protect users from a broad class of vulnerabilities. The security feature bypass by itself does not allow arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability, that could take advantage of the ASLR bypass to run arbitrary code.

This security update is rated Important for Microsoft .NET Framework 2.0 Service Pack 2, Microsoft .NET Framework 3.0 Service Pack 2, Microsoft .NET Framework 3.5, and Microsoft .NET Framework 3.5.1 on affected releases of Microsoft Windows. For more information, see the Affected and Non-Affected Software section.

The security update addresses the vulnerability by helping to ensure that affected versions of Microsoft .NET Framework properly implement the ASLR security feature. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability later in this bulletin.

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871. For customers who do not have automatic updating enabled, the steps in Turn automatic updating on or off can be used to enable automatic updating.

For administrators and enterprise installations, or end users who want to install this security update manually (including customers who have not enabled automatic updating), Microsoft recommends that customers apply the update at the earliest opportunity using update management software, or by checking for updates using the Microsoft Update service. The updates are also available via the download links in the Affected Software table later in this bulletin.

See also the section, Detection and Deployment Tools and Guidance, later in this bulletin.

• Knowledge Base Article: 2984625
• File Information: Yes
• SHA1/SHA2 hashes: Yes
• Known issues: Yes

The following software has been tested to determine which versions or editions are affected. Other versions or editions are either past their support life cycle or are not affected. To determine the support life cycle for your software version or edition, see Microsoft Support Lifecycle.

Affected Software 

Non-Affected Software

Non-Applicable Software

Why is Microsoft .NET Framework 1.1 Service Pack 1 not listed as affected software; why is Microsoft not issuing an update for it?
Although the affected code is present in Microsoft .NET Framework 1.1 Service Pack 1, it is infeasible to build the fix for it because the operating systems that support Microsoft .NET Framework 1.1 Service Pack 1 do not support the ASLR architecture. Building the fix would require re-architecting a significant amount of Microsoft .NET 1.1 Service Pack 1, and ASLR still would still not work correctly due to a lack of underlying operating system support.

How do I determine which version of the Microsoft .NET Framework is installed?
You can install and run multiple versions of the .NET Framework on a system, and you can install the versions in any order. There are several ways to determine which versions of the .NET Framework are currently installed. For more information, see Microsoft Knowledge Base Article 318785.****

There are multiple update packages available for some of the affected software. Do I need to install all the updates listed in the Affected Software table for the software?
Yes. Customers should apply all updates offered for the software installed on their systems.

Do I need to install these security updates in a particular sequence?
No. Multiple updates for a given system can be applied in any sequence.

I am using an older release of the software discussed in this security bulletin. What should I do? 
The affected software listed in this bulletin has been tested to determine which releases are affected. Other releases are past their support life cycle. For more information about the product lifecycle, see the Microsoft Support Lifecycle website.

It should be a priority for customers who have older releases of the software to migrate to supported releases to prevent potential exposure to vulnerabilities. To determine the support lifecycle for your software release, see Select a Product for Lifecycle Information. For more information about service packs for these software releases, see Service Pack Lifecycle Support Policy.

Customers who require custom support for older software must contact their Microsoft account team representative, their Technical Account Manager, or the appropriate Microsoft partner representative for custom support options. Customers without an Alliance, Premier, or Authorized Contract can contact their local Microsoft sales office. For contact information, see the Microsoft Worldwide Information website, select the country in the Contact Information list, and then click Go to see a list of telephone numbers. When you call, ask to speak with the local Premier Support sales manager. For more information, see the Microsoft Support Lifecycle Policy FAQ.

The following severity ratings assume the potential maximum impact of the vulnerability. For information regarding the likelihood, within 30 days of this security bulletin's release, of the exploitability of the vulnerability in relation to its severity rating and security impact, please see the Exploitability Index in the August bulletin summary. For more information, see Microsoft Exploitability Index.

A security feature bypass vulnerability exists in the Microsoft .NET Framework that could allow an attacker to bypass the Address Space Layout Randomization (ASLR) security feature, which helps protect users from a broad class of vulnerabilities. The security feature bypass by itself does not allow arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability, that could take advantage of the ASLR bypass to run arbitrary code.

To view this vulnerability as a standard entry in the Common Vulnerabilities and Exposures list, see CVE-2014-4062.

Microsoft has not identified any mitigating factors for this vulnerability.

Workaround refers to a setting or configuration change that does not correct the underlying vulnerability but would help block known attack vectors before you apply the update. Microsoft has tested the following workarounds and states in the discussion whether a workaround reduces functionality:

• Install the Force ASLR feature hotfix and enable the IFEO registry entry

  The Force ASLR feature, which is an addition to the ASLR feature for Windows 7 or Windows Server 2008 R2, makes it possible for applications to forcibly relocated images that are not built with the /DYNAMICBASE linker flag. Once installed, computer administrators and software developers can enable the Image File Execution Options (IFEO) in the registry to force ASLR behavior for non-ASLR images.

  For more information and installation instructions, see Microsoft Knowledge Base Article 2639308.

  Impact of workaround. Forcibly relocates images that are not built with support for ASLR, which can cause application compatibility problems.

  How to undo the workaround.

  Note See Microsoft Knowledge Base Article 2639308 for information on setting the IFEO registry entry to the default setting.

What is the scope of the vulnerability?
This is a security feature bypass vulnerability.

What causes the vulnerability?
The vulnerability exists when the Microsoft .NET Framework does not use the Address Space Layout Randomization (ASLR) security feature, allowing an attacker to more reliably predict the memory offsets of specific instructions in a given call stack.

What is ASLR?
Address Space Layout Randomization (ASLR) moves executable images into random locations when a system boots, which helps prevent an attacker from leveraging data at predictable locations. For a component to support ASLR, all components that it loads must also support ASLR. For example, if A.exe consumes B.dll and C.dll, all three must support ASLR. By default, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012, and Windows Server 2012 R2 will randomize system DLLs and EXEs, but DLLs and EXEs created by Independent Software Vendors (ISVs) must opt in to support ASLR using the /DYNAMICBASE linker option.

ASLR also randomizes heap and stack memory:

• When an application creates a heap in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012, and Windows Server 2012 R2, the heap manager will create that heap at a random location to help reduce the chance that an attempt to exploit a heap-based buffer overrun succeeds. Heap randomization is enabled by default for all applications running on Windows Vista and later.
• When a thread starts in a process linked with /DYNAMICBASE, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012, and Windows Server 2012 R2 move the thread's stack to a random location to help reduce the chance that a stack-based buffer overrun exploit will succeed.

What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could bypass the ASLR security feature. The security feature bypass by itself does not allow arbitrary code execution. However, an attacker could use this ASLR bypass vulnerability in conjunction with another vulnerability, such as a remote code execution vulnerability that could take advantage of the ASLR bypass to run arbitrary code.

How could an attacker exploit the vulnerability?
In a web-based attack scenario, an attacker could host a website that is used to 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 this vulnerability. An attacker would have no way to force users to visit a specially crafted website. Instead, an attacker would have to convince users to take action. For example, an attacker could trick users into clicking a link that takes them to the attacker's site.

When a user visits a website that contains malicious content using a web browser capable of instantiating COM components, such as Internet Explorer, the affected .NET Framework component can be loaded to bypass ASLR.

An attacker could tie this security feature bypass vulnerability to an additional vulnerability, usually a remote code execution vulnerability. The additional vulnerability would take advantage of the security feature bypass for exploitation. For example, a remote code execution vulnerability that is blocked by ASLR, could be exploited after a successful ASLR bypass.

What systems are primarily at risk from the vulnerability?
In the web-browsing scenario, successful exploitation of this vulnerability requires that a user is logged on and running an affected version of Microsoft .NET Framework. Therefore, any systems where a web browser is used frequently, such as workstations or terminal servers, are at the most risk from this vulnerability. Servers could be at more risk if administrators allow users to browse and read email on servers. However, best practices strongly discourage allowing this.

Does EMET help mitigate attacks that could 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 vulnerabilities in a given piece of software. EMET helps to mitigate this vulnerability in Microsoft .NET Framework on systems where EMET is installed and configured to work with Microsoft Office software.

For more information about EMET, see The Enhanced Mitigation Experience Toolkit.

What does the update do?
The update addresses the vulnerability by helping to ensure that affected versions of Microsoft .NET Framework properly implement the ASLR security feature.

When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through coordinated vulnerability disclosure.

When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited?
No. Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers when this security bulletin was originally issued.

Several resources are available to help administrators deploy security updates. 

• Microsoft Baseline Security Analyzer (MBSA) lets administrators scan local and remote systems for missing security updates and common security misconfigurations. 
• Windows Server Update Services (WSUS), Systems Management Server (SMS), and System Center Configuration Manager help administrators distribute security updates. 
• The Update Compatibility Evaluator components included with Application Compatibility Toolkit aid in streamlining the testing and validation of Windows updates against installed applications. 

For information about these and other tools that are available, see Security Tools for IT Pros. 

Reference Table

The following table contains the security update information for this software.

Reference Table

The following table contains the security update information for this software.

Reference Table

The following table contains the security update information for this software.

Reference Table

The following table contains the security update information for this software.

Reference Table

The following table contains the security update information for this software.

Reference Table

The following table contains the security update information for this software.

To improve security protections for customers, Microsoft provides vulnerability information to major security software providers in advance of each monthly security update release. Security software providers can then use this vulnerability information to provide updated protections to customers via their security software or devices, such as antivirus, network-based intrusion detection systems, or host-based intrusion prevention systems. To determine whether active protections are available from security software providers, please go to the active protections websites provided by program partners, listed in Microsoft Active Protections Program (MAPP) Partners.

How to obtain help and support for this security update

• Help installing updates: Support for Microsoft Update
• Security solutions for IT professionals: TechNet Security Troubleshooting and Support
• Help protect your computer that is running Windows from viruses and malware: Virus Solution and Security Center
• Local support according to your country: International Support

The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.

• V1.0 (August 12, 2014): Bulletin published.
• V1.1 (September 16, 2014): Bulletin revised to announce a detection change in the 2966827 update for Microsoft .NET Framework 3.0 Service Pack 2 on Windows 8 and Windows Server 2012. This is a detection change only. There were no changes to the update files. Customers who have already successfully updated their systems do not need to take any action.
• V1.2 (September 19, 2014): Bulletin revised with a change to the Known Issues entry in the Knowledge Base Article section from "None" to "Yes".

Page generated 2014-09-19 10:02Z-07:00.