Microsoft Security Bulletin MS09-061 - Critical

Microsoft .NET applications that are not malicious are not at risk for being compromised because of this vulnerability. Only applications built in a specifically malicious way could exploit this vulnerability.

In a Web-hosting scenario, an attacker must have permission to upload arbitrary ASP.NET pages to a Web site and ASP.NET must be installed on that Web server. In default configuration, an anonymous user cannot upload and run Microsoft .NET code on an Internet Information Server (IIS).

By default, Internet Explorer on Windows Server 2003 and Windows Server 2008 runs in a restricted mode that is known as Enhanced Security Configuration. This mode mitigates this vulnerability only in a Web-based attack scenario. See the FAQ section of this vulnerability for more information about Internet Explorer Enhanced Security Configuration.

Internet Explorer 8 disables the Microsoft .NET MIME Filter in the Internet zone. This feature of Internet Explorer 8 makes successful exploitation of this vulnerability more difficult by blocking a known technique for bypassing ASLR and DEP protection. Disabling the Microsoft .NET MIME Filter in the Internet zone does not make it impossible to exploit this vulnerability in Internet Explorer 8, but it does make it more difficult for malicious Web sites to reliably exploit it.

In a Web-browsing attack scenario, an attacker could host a Web site that contains a Web page that is used to exploit this vulnerability. In addition, compromised Web sites and Web sites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail or Instant Messenger message that takes users to the attacker's Web site.

An attacker who successfully exploited this vulnerability could gain the same user rights as the local user or the user account of ASP.NET. Users or accounts that are configured to have fewer user rights on the system could be less impacted than users or accounts that operate with administrative user rights.

Disable partially trusted Microsoft .NET applications

To disable all Microsoft .NET applications running at partial trust, including XAML browser applications (XBAPs) and Microsoft .NET applications located on the network, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –resetlockdown
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to complete this workaround.

Impact of workaround. Some Microsoft .NET applications will not run.

How to undo the workaround.

To reset the Microsoft .NET security policies to the defaults, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –reset
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to undo this workaround.

Disable XAML browser applications in Internet Explorer

You can help protect against this vulnerability by changing your settings to prompt before running XAML browser applications (XBAPs) or to disable XBAPs in the Internet and Local intranet security zones.

Impact of workaround. Microsoft .NET code will not run in Internet Explorer or will not run without a prompt. Disabling Microsoft .NET applications and components in the Internet and Local intranet security zones may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly.

How to undo the workaround.

Web browsing scenario
An attacker could host a specially crafted Web site that contains a specially crafted XBAP (XAML browser application) that could exploit this vulnerability and then convince a user to view the Web site. The attacker could also take advantage of compromised Web sites and Web sites that accept or host user-provided content or advertisements. These Web sites could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail message or in an Instant Messenger message that takes users to the attacker's Web site. It could also be possible to display specially crafted Web content by using banner advertisements or by using other methods to deliver Web content to affected systems.

Web hosting scenario
If a Web hosting environment allows users to upload custom ASP.NET applications, an attacker user could upload a malicious ASP.NET application that uses this vulnerability to break out of the sandbox used to prevent ASP.NET code from performing harmful actions on the server system.

Microsoft .NET Framework application scenario
An attacker could place a malicious Microsoft .NET Framework application on a network share and convince users on that network to execute this application.

Web browsing scenario
Successful exploitation of this vulnerability requires that a user is logged on and is visiting Web sites using a Web browser capable of instantiating XBAPs. 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 e-mail on servers. However, best practices strongly discourage allowing this.

Web hosting scenario
Web hosting sites that allow users to upload custom ASP.NET applications are at increased risk.

Microsoft .NET applications that are not malicious are not at risk for being compromised because of this vulnerability. Only applications built in a specifically malicious way could exploit this vulnerability.

In a Web-hosting scenario, an attacker must have permission to upload arbitrary ASP.NET pages to a Web site and ASP.NET must be installed on that Web server. In default configuration, an anonymous user cannot upload and run Microsoft .NET code on an Internet Information Server (IIS).

By default, Internet Explorer on Windows Server 2003 and Windows Server 2008 runs in a restricted mode that is known as Enhanced Security Configuration. This mode mitigates this vulnerability only in a Web-based attack scenario. See the FAQ section of this vulnerability for more information about Internet Explorer Enhanced Security Configuration.

Internet Explorer 8 disables the Microsoft .NET MIME Filter in the Internet zone. This feature of Internet Explorer 8 makes successful exploitation of this vulnerability more difficult by blocking a known technique for bypassing ASLR and DEP protection. Disabling the Microsoft .NET MIME Filter in the Internet zone does not make it impossible to exploit this vulnerability in Internet Explorer 8, but it does make it more difficult for malicious Web sites to reliably exploit it.

In a Web-based attack scenario, an attacker could host a Web site that contains a Web page that is used to exploit this vulnerability. In addition, compromised Web sites and Web sites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail or Instant Messenger message that takes users to the attacker's Web site.

An attacker who successfully exploited this vulnerability could gain the same user rights as the local user or the user account of ASP.NET. Users or accounts that are configured to have fewer user rights on the system could be less impacted than users or accounts that operate with administrative user rights.

Disable partially trusted Microsoft .NET applications

To disable all Microsoft .NET applications running at partial trust, including XAML browser applications (XBAPs) and Microsoft .NET applications located on the network, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –resetlockdown
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to complete this workaround.

Impact of workaround. Some Microsoft .NET applications will not run.

How to undo the workaround.

To reset the Microsoft .NET security policies to the defaults, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –reset
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to undo this workaround.

Disable XAML browser applications in Internet Explorer

You can help protect against this vulnerability by changing your settings to prompt before running XAML browser applications (XBAPs) or to disable XBAPs in the Internet and Local intranet security zones.

Impact of workaround. Microsoft .NET code will not run in Internet Explorer or will not run without a prompt. Disabling Microsoft .NET applications and components in the Internet and Local intranet security zones may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly.

How to undo the workaround.

Web browsing scenario
An attacker could host a specially crafted Web site that contains a specially crafted XBAP (XAML browser application) that could exploit this vulnerability and then convince a user to view the Web site. The attacker could also take advantage of compromised Web sites and Web sites that accept or host user-provided content or advertisements. These Web sites could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail message or in an Instant Messenger message that takes users to the attacker's Web site. It could also be possible to display specially crafted Web content by using banner advertisements or by using other methods to deliver Web content to affected systems.

Web hosting scenario
If a Web hosting environment allows users to upload custom ASP.NET applications, an attacker user could upload a malicious ASP.NET application that uses this vulnerability to break out of the sandbox used to prevent ASP.NET code from performing harmful actions on the server system.

Microsoft .NET Framework application scenario
An attacker could place a malicious Microsoft .NET Framework application on a network share and convince users on that network to execute this application.

Web browsing scenario
Successful exploitation of this vulnerability requires that a user is logged on and is visiting Web sites using a Web browser capable of instantiating XBAPs. 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 e-mail on servers. However, best practices strongly discourage allowing this.

Web hosting scenario
Web hosting sites that allow users to upload custom ASP.NET applications are at increased risk.

The current version of Microsoft Silverlight, Silverlight 3, is not affected by this vulnerability. By default, Silverlight will periodically check a Microsoft Web site for updates to provide you with the latest features and improvements. If a newer version is available, it will be downloaded and installed on your computer. Most systems will already be running a version of Silverlight 3. For more information, see Microsoft Silverlight Updater.

Microsoft .NET applications that are not malicious are not at risk for being compromised because of this vulnerability. Only applications built in a specifically malicious way could exploit this vulnerability.

In a Web-hosting scenario, an attacker must have permission to upload arbitrary ASP.NET pages to a Web site and ASP.NET must be installed on that Web server. In default configuration, an anonymous user cannot upload and run Microsoft .NET code on an Internet Information Server (IIS).

By default, Internet Explorer on Windows Server 2003 and Windows Server 2008 runs in a restricted mode that is known as Enhanced Security Configuration. This mode mitigates this vulnerability only in a Web-based attack scenario. See the FAQ section of this vulnerability for more information about Internet Explorer Enhanced Security Configuration.

Internet Explorer 8 disables the Microsoft .NET MIME Filter in the Internet Zone. This feature of Internet Explorer 8 makes successful exploitation of this vulnerability more difficult in Internet Explorer 8 by blocking a known technique for bypassing ASLR and DEP protection. This does not make it impossible to exploit this vulnerability in Internet Explorer 8, but it does make it more difficult for malicious Web sites to reliably exploit it.

In a Web-based attack scenario, an attacker could host a Web site that contains a Web page that is used to exploit this vulnerability. In addition, compromised Web sites and Web sites that accept or host user-provided content or advertisements could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail or Instant Messenger message that takes users to the attacker's Web site.

An attacker who successfully exploited this vulnerability could gain the same user rights as the local user or the user account of ASP.NET. Users or accounts that are configured to have fewer user rights on the system could be less impacted than users or accounts that operate with administrative user rights.

Disable partially trusted Microsoft .NET applications

To disable all Microsoft .NET applications running at partial trust, including XBAPs and Microsoft .NET applications located on the network, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –resetlockdown
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to complete this workaround.

Impact of workaround. Some Microsoft .NET applications will not run.

How to undo the workaround.

To reset the Microsoft .NET security policies to the defaults, run the following commands from an elevated command prompt:

caspol –pp off
caspol –m –reset
caspol –pp on

Note You must be logged in as administrator or have administrative credentials to undo this workaround.

Disable XAML browser applications in Internet Explorer

You can help protect against this vulnerability by changing your settings to prompt before running XAML browser applications or to disable XAML browser applications in the Internet and Local intranet security zones.

Impact of workaround. Microsoft .NET code will not run in Internet Explorer or will not run without a prompt. Disabling Microsoft .NET applications and components in the Internet and Local Intranet security zones may cause some Web sites to work incorrectly. If you have difficulty using a Web site after you change this setting and you are sure the site is safe to use, you can add that site to your list of trusted sites. This will allow the site to work correctly.

How to undo the workaround.

Temporarily prevent the Microsoft Silverlight ActiveX control from running in Internet Explorer on Windows XP Service Pack 2 or later

You can help protect against these vulnerabilities by temporarily preventing the Silverlight ActiveX control from running in Internet Explorer. You can use the Internet Explorer Manage Add-ons feature to disable the ActiveX control.

Note If you cannot locate the ActiveX control, use the drop-down box to switch from "Add-ons currently being used in Internet Explorer" to "Add-ons that have been used by Internet Explorer", or from "Currently loaded add-ons" to "All add-ons", and then follow steps 2 and 3. If the ActiveX control is not present in this list you either have not used the ActiveX control before or it is not present on your system.

Note This workaround is intended only for systems on which Silverlight is already installed, and cannot be used proactively on systems where Silverlight is not yet installed.

For more information on the Internet Explorer Manage Add-ons feature in Windows XP Service Pack 2, see Microsoft Knowledge Base Article 883256.

Impact of workaround. Applications and Web sites that require the Microsoft Silverlight ActiveX control may no longer function correctly. If you implement this workaround it would affect any Silverlight ActiveX control you have installed on your system.

How to undo the workaround.

Temporarily prevent the Microsoft Silverlight ActiveX control from running in Internet Explorer

You can help protect against these vulnerabilities by temporarily preventing attempts to instantiate the Silverlight ActiveX control in Internet Explorer by setting the kill bit for the control.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

We recommend that you back up the registry before you edit it.

Use the following text to create a .reg file that temporarily prevents attempts to instantiate the Silverlight ActiveX control in Internet Explorer. You can copy the following text, paste it into a text editor such as Notepad, and then save the file with the .reg file name extension. Run the .reg file on the vulnerable client.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{DFEAF541-F3E1-4C24-ACAC-99C30715084A}]

Close Internet Explorer and reopen it for the changes to take effect.

For detailed steps about stopping a control from running in Internet Explorer, see Microsoft Knowledge Base Article 240797. Follow these steps and create a Compatibility Flags value in the registry to prevent the Silverlight ActiveX control from running in Internet Explorer.

Impact of workaround. Applications and Web sites that require the Microsoft Silverlight ActiveX control may no longer function correctly. If you implement this workaround it would affect any Silverlight ActiveX control you have installed on your system.

How to undo the workaround. Remove the registry keys added to temporarily prevent attempts to instantiate the Silverlight ActiveX control in Internet Explorer.

Web browsing scenario
An attacker could host a specially crafted Web site that contains a specially crafted XBAP (XAML browser application) or Silverlight application that could exploit this vulnerability and then convince a user to view the Web site. The attacker could also take advantage of compromised Web sites and Web sites that accept or host user-provided content or advertisements. These Web sites could contain specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to visit these Web sites. Instead, an attacker would have to convince users to visit the Web site, typically by getting them to click a link in an e-mail message or in an Instant Messenger message that takes users to the attacker's Web site. It could also be possible to display specially crafted Web content by using banner advertisements or by using other methods to deliver Web content to affected systems.

Web hosting scenario
If a Web hosting environment allows users to upload custom ASP.NET applications, an attacker could upload a malicious ASP.NET application that uses this vulnerability to break out of the sandbox used to prevent ASP.NET code from performing harmful actions on the server system.

Microsoft .NET Framework application scenario
An attacker could place a malicious Microsoft .NET Framework application on a network share and convince users on that network to execute this application.

Web browsing scenario
Successful exploitation of this vulnerability requires that a user is logged on and is visiting Web sites using a Web browser capable of instantiating XBAPs or Silverlight applications. 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 e-mail on servers. However, best practices strongly discourage allowing this.

Web hosting scenario
Web hosting sites that allow users to upload custom ASP.NET applications are at increased risk.