Microsoft Security Bulletin MS10-060 - Critical

Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. The following mitigating factors may be helpful in your situation:

• 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 message 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. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
• By default, all supported versions of Microsoft Outlook and Microsoft Outlook Express open HTML e-mail messages in the Restricted sites zone. The Restricted sites zone helps mitigate attacks that could try to exploit this vulnerability by preventing Active Scripting and ActiveX controls from being used when reading HTML e-mail messages. However, if a user clicks a link in an e-mail message, the user could still be vulnerable to exploitation of this vulnerability through the Web-based attack scenario.
• 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 sets the security level for the Internet zone to High. This is a mitigating factor for Web sites that you have not added to the Internet Explorer Trusted sites zone. See the FAQ subsection of this vulnerability section for more information about Internet Explorer Enhanced Security Configuration.

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:

• Set Internet and Local intranet security zone settings to "High" to block ActiveX Controls and Active Scripting in these zones

  You can help protect against exploitation of this vulnerability by changing your settings for the Internet security zone to block ActiveX controls and Active Scripting. You can do this by setting your browser security to High.

  To raise the browsing security level in Internet Explorer, follow these steps:

  1. On the Internet Explorer Tools menu, click Internet Options.
  2. In the Internet Options dialog box, click the Security tab, and then click the Internet icon.
  3. Under Security level for this zone, move the slider to High. This sets the security level for all Web sites you visit to High.

  Note If no slider is visible, click Default Level, and then move the slider to High.

  Note Setting the level to High 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 even with the security setting set to High.

  Impact of workaround. There are side effects to blocking ActiveX Controls and Active Scripting. Many Web sites that are on the Internet or on an intranet use ActiveX or Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use ActiveX Controls to provide menus, ordering forms, or even account statements. Blocking ActiveX Controls or Active Scripting is a global setting that affects all Internet and intranet sites. If you do not want to block ActiveX Controls or Active Scripting for such sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".

  Add sites that you trust to the Internet Explorer Trusted sites zone

  After you set Internet Explorer to block ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone. This will allow you to continue to use trusted Web sites exactly as you do today, while helping to protect yourself from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone.

  To do this, follow these steps:

  1. In Internet Explorer, click Tools, click Internet Options, and then click the Security tab.
  2. In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites.
  3. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box.
  4. In the Add this Web site to the zone box, type the URL of a site that you trust, and then click Add.
  5. Repeat these steps for each site that you want to add to the zone.
  6. Click OK two times to accept the changes and return to Internet Explorer.

  Note Add any sites that you trust not to take malicious action on your system. Two in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com. These are the sites that will host the update, and it requires an ActiveX Control to install the update.

• Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone

  You can help protect against exploitation of this vulnerability by changing your settings to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone. To do this, follow these steps:

  1. In Internet Explorer, click Internet Options on the Tools menu.
  2. Click the Security tab.
  3. Click Internet, and then click Custom Level.
  4. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK.
  5. Click Local intranet, and then click Custom Level.
  6. Under Settings, in the Scripting section, under Active Scripting, click Prompt or Disable, and then click OK.
  7. Click OK two times to return to Internet Explorer.

  Note Disabling Active Scripting 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.

  Impact of workaround. There are side effects to prompting before running Active Scripting. Many Web sites that are on the Internet or on an intranet use Active Scripting to provide additional functionality. For example, an online e-commerce site or banking site may use Active Scripting to provide menus, ordering forms, or even account statements. Prompting before running Active Scripting is a global setting that affects all Internet and intranet sites. You will be prompted frequently when you enable this workaround. For each prompt, if you feel you trust the site that you are visiting, click Yes to run Active Scripting. If you do not want to be prompted for all these sites, use the steps outlined in "Add sites that you trust to the Internet Explorer Trusted sites zone".

  Add sites that you trust to the Internet Explorer Trusted sites zone

  After you set Internet Explorer to require a prompt before it runs ActiveX controls and Active Scripting in the Internet zone and in the Local intranet zone, you can add sites that you trust to the Internet Explorer Trusted sites zone. This will allow you to continue to use trusted Web sites exactly as you do today, while helping to protect you from this attack on untrusted sites. We recommend that you add only sites that you trust to the Trusted sites zone.

  To do this, follow these steps:

  1. In Internet Explorer, click Tools, click Internet Options, and then click the Security tab.
  2. In the Select a Web content zone to specify its current security settings box, click Trusted Sites, and then click Sites.
  3. If you want to add sites that do not require an encrypted channel, click to clear the Require server verification (https:) for all sites in this zone check box.
  4. In the Add this Web site to the zone box, type the URL of a site that you trust, and then click Add.
  5. Repeat these steps for each site that you want to add to the zone.
  6. Click OK two times to accept the changes and return to Internet Explorer.

  Note Add any sites that you trust not to take malicious action on your system. Two in particular that you may want to add are *.windowsupdate.microsoft.com and *.update.microsoft.com. These are the sites that will host the update, and it requires an ActiveX Control to install the update.

• Temporarily prevent the Microsoft Silverlight ActiveX control from running in Internet Explorer (Method 1)

  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.

  Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{DFEAF541-F3E1-4C24-ACAC-99C30715084A}]
"Compatibility Flags"=dword:00000400

  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.

• Temporarily prevent the Microsoft Silverlight ActiveX control from running in Internet Explorer (Method 2)

  To modify the registry key to disable Microsoft Silverlight, follow these steps:

  Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or view the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe.

  • Using the Interactive Method
    1. Click Start, click Run, type Regedit in the Open box, and then click OK.
    2. Locate and then click the following registry subkey:
       
       HKEY_CLASSES_ROOT\CLSID\{DFEAF541-F3E1-4c24-ACAC-99C30715084A}
    3. Right click on {DFEAF541-F3E1-4c24-ACAC-99C30715084A} and select Export. Save the file to disk.
    4. Delete the entire {DFEAF541-F3E1-4c24-ACAC-99C30715084A} key.
    5. Quit the registry editor.
  • Using a registry file
    1. Create a backup copy of the registry keys. A backup copy can be made using a managed deployment script with the following command:
       
       Regedit.exe /e SL_backup.reg HKEY_CLASSES_ROOT\CLSID\{DFEAF541-F3E1-4c24-ACAC-99C30715084A}
    2. Save the following to a file with a .REG extension (e.g. Disable_Silverlight.reg):
       
       Windows Registry Editor Version 5.00
       [-HKEY_CLASSES_ROOT\CLSID\{DFEAF541-F3E1-4c24-ACAC-99C30715084A}]
    3. Run the above registry script created in step 2 on the target system with the following command:
       Regedit /s Disable_Silverlight.reg

  How to undo the workaround.

  • Using the Interactive Method
    1. Click Start, click Run, type Regedit in the Open box, and then click OK.
    2. On the File menu, click Import.
    3. In Look in, select the drive, folder, or network computer and folder where the file you previously exported is located.
    4. Select the correct file name and then click Open.
  • Using a Managed Deployment Script

    Restore the file backed up in Step 1 above with the following command:
    
    Regedit /s SL_backup.reg

• Temporarily prevent the Microsoft Silverlight ActiveX control from running in Firefox or Chrome

  To modify the registry key to disable Microsoft Silverlight, follow these steps:

  Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" Help topic in Registry Editor (Regedit.exe) or view the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe.

  • Using the Interactive Method
    1. Click Start, click Run, type Regedit in the Open box, and then click OK.
    2. Locate and then click the following registry subkey:
       
       HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0
    3. Right click on @Microsoft.com/NpCtrl,version=1.0 and select Export. Save the file to disk.
    4. Delete the entire @Microsoft.com/NpCtrl,version=1.0 key.
    5. Quit the registry editor.
  • Using a registry file
    1. Create a backup copy of the registry keys. A backup copy can be made using a managed deployment script with the following command:
       
       Regedit.exe /e SL_backup.reg HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0
    2. Save the following to a file with a .REG extension (e.g. Disable_Silverlight.reg):
       
       Windows Registry Editor Version 5.00
       [-HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins\@Microsoft.com/NpCtrl,version=1.0]
    3. Run the above registry script created in step 2 on the target system with the following command:
       Regedit /s Disable_Silverlight.reg

  How to undo the workaround.

  • Using the Interactive Method
    1. Click Start, click Run, type Regedit in the Open box, and then click OK.
    2. On the File menu, click Import.
    3. In Look in, select the drive, folder, or network computer and folder where the file you previously exported is located.
    4. Select the correct file name and then click Open.
  • Using a Managed Deployment Script

    Restore the file backed up in Using a registry file Step 1, above, with the following command:
    
    Regedit /s SL_backup.reg

What is the scope of the vulnerability? 
If Microsoft Silverlight is installed on a system, this vulnerability can allow remote code execution in the context of the currently logged-on user.

What causes the vulnerability? 
The vulnerability is caused by the way that Silverlight handles pointers. When Silverlight parses specially crafted Silverlight code, a memory corruption can occur that may either cause Silverlight to stop responding, or allow code execution.

What is Silverlight? 
Microsoft Silverlight is a cross-browser, cross-platform implementation of the Microsoft .NET Framework for building media experiences and rich interactive applications for the Web. For more information, see the official site of Microsoft Silverlight.

What might an attacker use the vulnerability to do? 
If a user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

How could an attacker exploit the vulnerability? 
An attacker could host a specially crafted Web site that is designed to exploit this vulnerability and then convince a user to visit the Web site. This could also include 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 these vulnerabilities. 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.

What systems are primarily at risk from the vulnerability? 
Successful exploitation of this vulnerability requires that a user is logged on and is visiting Web sites using a Web browser capable of instantiating Silverlight applications. Therefore, any systems on which Microsoft Silverlight is installed, on either the Microsoft Windows or Apple Mac OS platform, are primarily at risk. 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.

I am running Internet Explorer for Windows Server 2003 or Windows Server 2008. Does this mitigate this vulnerability? 
Yes. By default, Internet Explorer on Windows Server 2003 and Windows Server 2008 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 Web sites that you have not added to the Internet Explorer Trusted sites zone. See also Managing Internet Explorer Enhanced Security Configuration.

What does the update do? 
This update modifies the way in which Microsoft Silverlight handles pointers.

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.

Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of exploitation of a vulnerability. The following mitigating factors may be helpful in your situation:

• 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.
• 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.
• 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.
• 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-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).
• The current version of Microsoft Silverlight, Silverlight 4, 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 4. For more information, see Microsoft Silverlight Updater.

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:

• 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.

  1. Tools menu and then select Internet Options.
  2. Security tab, click Internet, and then click Custom level.
  3. Settings, for Loose XAML, click Prompt or Disable, and then click OK. Repeat these steps for XAML browser applications and XPS documents.
  4. Security tab, click Custom level, under .NET Framework-reliant components, for Run components not signed with Authenticode, click Prompt or Disable, and then click OK. Repeat these steps for Run components signed with Authenticode, and then click OK.
  5. Local intranet, and then click Custom Level. Repeat steps 3 and 4. If you are prompted to confirm that you want to change these settings, click Yes. Click OK to return to Internet Explorer.

  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.

  1. Tools menu and then select Internet Options.
  2. Security tab, click Reset all zones to default level, and then click OK.
• 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.

  1. Tools menu and then select Manage Add-ons.
  2. Microsoft Silverlight.
  3. Disable, and then click OK.

  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.

  1. Tools menu and then select Manage Add-ons.
  2. Microsoft Silverlight, click Enable, and then click OK.
• 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.

  Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{DFEAF541-F3E1-4C24-ACAC-99C30715084A}]
"Compatibility Flags"=dword:00000400

  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.

• Upgrade to the latest version of Microsoft Silverlight

  Silverlight 4 is not affected by this vulnerability. Instead of installing the Silverlight security update, customers can upgrade to the latest version of Silverlight. For more information, see Microsoft Silverlight.

What is the scope of the vulnerability? 
This vulnerability is a remote code execution vulnerability in either the context of the currently logged-on user, or in the context of the service account associated with an application pool identity.

What causes the vulnerability? 
This vulnerability results from the manner in which the Microsoft .NET Common Language Runtime (CLR) handles delegates to virtual methods.

What is the CLR? 
The Microsoft .NET Framework provides a run-time environment called the Common Language Runtime (CLR), which runs the code and provides services that make the development process easier. For more information about the CLR, see Common Language Runtime Overview.

What is an XBAP? 
An XAML browser application (XBAP) combines features of both a Web application and a rich-client application. Like Web applications, XBAPs can be published to a Web server and launched from Internet Explorer. Like rich-client applications, XBAPs can take advantage of the capabilities of Windows Presentation Foundation (WPF). For more information about XBAPs, see Windows Presentation Foundation XAML Browser Applications Overview.

What is Silverlight? 
Microsoft Silverlight is a cross-browser, cross-platform implementation of the Microsoft .NET Framework for building media experiences and rich interactive applications for the Web. For more information, see the official site of Microsoft Silverlight.

I am running Internet Explorer for Windows Server 2003 or Windows Server 2008. Does this mitigate this vulnerability? 
Yes and no. For the Web browsing attack scenario, running Internet Explorer on Windows Server 2003 or Windows Server 2008 mitigates the vulnerability, but for the Web hosting and .NET Application attack scenario, these platforms do not mitigate the vulnerability. By default, Internet Explorer on Windows Server 2003 and Windows Server 2008 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 Web sites that you have not added to the Internet Explorer Trusted sites zone. See also Managing Internet Explorer Enhanced Security Configuration.

What might an attacker use the vulnerability to do? 
An attacker who successfully exploited this vulnerability could obtain the same permissions as the currently logged-on user. If a user is logged on with administrative user rights, an attacker could take complete control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

In the Web hosting scenario, an attacker who successfully exploits this vulnerability could obtain the same permissions as the service account associated with the application pool identity of the application pool that a Microsoft .NET application is running under. Depending on application pool isolation configuration and permissions granted to the service account, an attacker might be able to take control over other application pools on the Web server or be able to take complete control of the affected system. For more information about application pool identities and configuration, see Configure Application Pool Identity.

How could an attacker exploit the vulnerability? 
There are three scenarios possible for exploitation of this vulnerability: a Web browsing scenario, a Web hosting scenario, and a Microsoft .NET Framework application scenario. These scenarios are described below.

• 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.

What systems are primarily at risk from the vulnerability? 
There are two types of systems at risk from this vulnerability, described below: systems that are using the Web browsing scenario, and systems that are using the Web hosting scenario.

• 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.

What does the update do? 
This update modifies the way in which the Microsoft .NET CLR handles interfaces.

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.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.

Note For supported versions of Windows XP Professional x64 Edition, this security update is the same as supported versions of the Windows Server 2003 x64 Edition security update.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.

Reference Table

The following table contains the security update information for this software. You can find additional information in the subsection, Deployment Information, in this section.