Microsoft Security Bulletin MS04-011

• Only Windows 2000 and Windows XP can be remotely attacked by an anonymous user. While Windows Server 2003 and Windows XP 64-Bit Edition Version 2003 contain the vulnerability, only a local administrator could exploit it.
• Windows NT 4.0 is not affected by this vulnerability.
• Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Create a file called %systemroot%\debug\dcpromo.log and make the file read-only. To do this, type the following command:

  echo dcpromo >%systemroot%\debug\dcpromo.log & attrib +r %systemroot%\debug\dcpromo.log

  Note This is the most effective mitigation technique as it completely mitigates this vulnerability by causing the vulnerable code to never be executed. This work-around will work for packets sent to any vulnerable port.

• Use a personal firewall such as the Internet Connection Firewall, which is included with Windows XP and Windows Server 2003.

  If you use the Internet Connection Firewall feature in Windows XP or in Windows Server 2003 to help protect your Internet connection, it blocks unsolicited inbound traffic by default. Microsoft recommends blocking all unsolicited inbound communication from the Internet.

  To enable the Internet Connection Firewall feature by using the Network Setup Wizard, follow these steps:

  1. Click Start, and then click Control Panel.
  2. In the default Category View, click Network and Internet Connections, and then click Setup or change your home or small office network. The Internet Connection Firewall feature is enabled when you select a configuration in the Network Setup Wizard that indicates that your system is connected directly to the Internet.

  To configure Internet Connection Firewall manually for a connection, follow these steps:

  1. Click Start, and then click Control Panel.
  2. In the default Category View, click Networking and Internet Connections, and then click Network Connections.
  3. Right-click the connection on which you want to enable Internet Connection Firewall, and then click Properties.
  4. Click the Advanced tab.
  5. Click to select the Protect my computer or network by limiting or preventing access to this computer from the Internet check box, and then click OK.

  Note If you want to enable the use of some programs and services through the firewall, click Settings on the Advanced tab, and then select the programs, protocols, and services needed.

• Block the following at the firewall:
  • UDP ports 135, 137, 138, and 445, and TCP ports 135, 139, 445, and 593
  • All unsolicited inbound traffic on ports greater than 1024
  • Any other specifically configured RPC port

  These ports are used to initiate a connection with RPC. Blocking them at the firewall will help prevent systems that are behind that firewall from attempts to exploit this vulnerability. Also, make sure that you block any other specifically configured RPC port on the remote system. Microsoft recommends that you block all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports. For more information about the ports that RPC uses, visit the following Web site.

• Enable advanced TCP/IP filtering on systems that support this feature.

  You can enable advanced TCP/IP filtering to block all unsolicited inbound traffic. For more information about how to configure TCP/IP filtering, see Microsoft Knowledge Base Article 309798.

• Block the affected ports by using IPSec on the affected systems.

  Use Internet Protocol Security (IPSec) to help protect network communications. Detailed information about IPSec and how to apply filters is available in Microsoft Knowledge Base Articles 313190 and 813878.

What is the scope of the vulnerability?
This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could remotely take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?
An unchecked buffer in the LSASS service.

What is LSASS?
Local Security Authority Subsystem Service (LSASS) provides an interface for managing local security, domain authentication, and Active Directory processes. It handles authentication for the client and for the server. It also contains features that are used to support Active Directory utilities.

What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability could take complete control of the affected system.

Who could exploit the vulnerability?
On Windows 2000 and Windows XP, any anonymous user who could deliver a specially crafted message to the affected system could attempt to exploit this vulnerability.

How could an attacker exploit this vulnerability?
An attacker could exploit the vulnerability by creating a specially crafted message and sending the message to an affected system, which could then cause the affected system to execute code.

An attacker could also access the affected component through another vector. For example, an attacker could log on to the system interactively or by using another program that passes parameters to the vulnerable component (locally or remotely).

What systems are primarily at risk from the vulnerability?
Windows 2000 and Windows XP are primarily at risk from this vulnerability.

Windows Server 2003 and Windows XP 64-Bit Edition Version 2003 provide additional protection that would require an administrator to log on locally to an affected system to exploit this vulnerability.

What does the update do?
The update removes the vulnerability by modifying the way that LSASS validates the length of a message before it passes the message to the allocated buffer.

This update also removes the vulnerable code from Windows 2000 Professional and from Windows XP because these operating systems do not require the vulnerable interface. This helps protect against possible future vulnerabilities in this service.

• To exploit this vulnerability, an attacker would have to send a specially crafted LDAP message to the domain controller. If the LDAP ports are not blocked by a firewall, an attacker would not require any additional privileges to exploit this vulnerability.
• This vulnerability only affects Windows 2000 Server domain controllers; Windows Server 2003 domain controllers are not affected.
• Windows NT 4.0 and Windows XP are not affected by this vulnerability.
• If an attacker successfully exploited this vulnerability, the affected system might display a warning that it would automatically restart after a 60-second countdown. At the end of this 60-second countdown, the affected system would automatically restart. After restart, the affected system would be restored to normal functionality. However, the affected system could be susceptible to a new denial of service attack unless the update is applied.
• Firewall best practices and standard default firewall configurations can help protect networks from attacks originating outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Block LDAP TCP ports 389, 636, 3268, and 3269 at your firewall.

  These ports are used to initiate an LDAP connection with a Windows 2000 domain controller. Blocking them at the firewall will help prevent systems that are behind that firewall from attempts to exploit this vulnerability that originate outside the enterprise perimeter. While other ports could be used to exploit this vulnerability, the ports listed are the most common attack vectors. Microsoft recommends blocking all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports.

  Impact of workaround: Active Directory domain authentication will not be possible over a network connection where these ports are blocked.

What’s the scope of the vulnerability?

This is a denial of service vulnerability. An attacker who exploited this vulnerability could cause the server to automatically restart and, during that time, stop the server from responding to authentication requests. This vulnerability exists in Windows 2000 Server systems that perform the role of a domain controller. The only effect on other Windows 2000 systems is that clients may not be able to log on to the domain if their domain controller stops responding.

What causes the vulnerability?

The processing of specially crafted LDAP messages by the Local Security Authority Subsystem Service (LSASS).

What is LDAP?

Lightweight Directory Access Protocol (LDAP) is an industry-standard protocol that enables authorized users to query or modify the data in a metadirectory. For example, in Windows 2000, LDAP is one protocol that is used to access data in Active Directory.

What’s wrong with the way the specially crafted LDAP messages are handled?

An attacker could send a specially crafted LDAP message to the LSASS service and cause it to stop responding.

What is LSASS?

Local Security Authority Subsystem Service (LSASS) provides an interface for managing local security, domain authentication, and Active Directory processes. It handles authentication for the client and for the server. It also contains features that are used to support Active Directory utilities.

What might an attacker use the vulnerability to do?

An attacker who exploited this vulnerability could cause LSASS to stop responding and the affected system to restart. The affected system might display a warning that it would automatically restart after a 60-second countdown. During this 60 second countdown, local authentication at the console of the affected system and user domain authentication with the affected system would not be possible. At the end of this 60-second countdown, the affected system would automatically restart. If users cannot perform domain authentication with the affected system, they might not be able to access domain resources. After restart, the affected system would be restored to normal functionality. However, it could be susceptible to a new denial of service attack unless the update is applied.

Who could exploit the vulnerability?

Any anonymous user who could deliver the specially crafted LDAP message to the affected system could exploit this vulnerability.

How could an attacker exploit the vulnerability?

An attacker could exploit this vulnerability by sending a specially crafted LDAP message to the domain controllers in a single forest or multiple forests, potentially causing a denial of service to domain authentication throughout an enterprise. This could cause LSASS to stop responding and cause the affected system to restart. An attacker does not have to have a valid user account in the domain to send this specially crafted LDAP message. This attack can be performed by using anonymous access.

What systems are primarily at risk from the vulnerability?

Only Windows 2000 domain controllers are vulnerable.

I am running Windows 2000. What systems do I have to update?

The update to address this vulnerability must be installed on systems that are used as Windows 2000 domain controllers. However, the update can be safely installed on Windows 2000 Servers in other roles. Microsoft recommends that you install this update on systems that might be promoted to domain controllers in the future.

What does the update do?

The update removes the vulnerability by modifying the way that LSASS processes the specially crafted LDAP message.

• Only systems that have enabled SSL are affected, typically only server systems. SSL support is not enabled by default on any of the affected systems. However, SSL is generally used on Web servers to support electronic commerce programs, online banking, and other programs that require secure communications.
• Windows Server 2003 is only vulnerable to this issue if an administrator has manually enabled PCT (even if SSL has been enabled).
• In some situations, the Web Publishing features of ISA Server 2000 or Proxy Server 2.0 can successfully block attempts to exploit this vulnerability. Testing has shown that the Web publishing features of ISA Server 2000, with Packet Filtering enabled and all Packet Filtering options selected can successfully block this attack with no noticeable side effects. Proxy Server 2.0 also successfully blocks this attack. However, until the security update is applied on the Proxy Server 2.0 system, this attack causes Proxy Server 2.0 Web services to stop responding and the system must be restarted.
• Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Disable PCT support through the registry

  This workaround is fully documented in Microsoft Knowledge Base Article 187498. This article is summarized below.

  The following steps demonstrate how to disable the PCT 1.0 protocol that prevents the affected system from negotiating its use.

  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 the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe.

  Note It is a good idea to back up the registry before you edit it.

  1. Click Start, click Run, type "regedt32" (without the quotation marks), and then click OK.
  2. In Registry Editor, locate the following registry key:

     HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server

  3. In the Edit menu, click Add Value to create a new REG_DWORD value called "Enabled" in the Server subkey.
  4. In the Data Type list, click REG_DWORD.
  5. In the Value Name text box, type "Enabled" (without the quotation marks), and then click OK.

     Note If this value is already present, double-click on the value to edit its current value, and then go to step 6.

  6. In the Binary Editor, set the new keys value to equal 0 by typing the following string: 00000000.
  7. Click OK, and then restart the system.

     Note To enable PCT, change the value of the Enabled registry key to 00000001, and then restart the system.

     Note If you are using Windows XP RTM you must also create a second registry key to fully disable PCT. This is not required on later versions of Windows XP or other affected operating systems. Use the instructions provided earlier and create a second REG_DWORD value named “Client”. Use the same values as documented earlier.

What’s the scope of the vulnerability?

A buffer overrun vulnerability exists in the Private Communications Transport (PCT) protocol, which is part of the Microsoft Secure Sockets Layer (SSL) library. Only systems that have SSL enabled, and in some cases Windows 2000 domain controllers, are vulnerable.

All programs that use SSL could be affected. Although SSL is generally associated with Internet Information Services by using HTTPS and port 443, any service that implements SSL on an affected platform is likely to be vulnerable. This includes but is not limited to, Microsoft Internet Information Services 4.0, Microsoft Internet Information Services 5.0, Microsoft Internet Information Services 5.1, Microsoft Exchange Server 5.5, Microsoft Exchange Server 2000, Microsoft Exchange Server 2003, Microsoft Analysis Services 2000 (included with SQL Server 2000), and any third-party programs that use PCT. SQL Server 2000 is not vulnerable because it specifically blocks PCT connections.

Windows Server 2003 and Internet Information Services 6.0 are only vulnerable to this issue if an administrator has manually enabled PCT (even if SSL has been enabled).

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

The process used by the SSL Library to check message inputs.

What is the SSL library?

The Microsoft Secure Sockets Layer (SSL) library contains support for a number of secure communication protocols. These include Transport Layer Security 1.0 (TLS 1.0), Secure Sockets Layer 3.0 (SSL 3.0), and the older and seldom-used Secure Sockets Layer 2.0 (SSL 2.0), and Private Communication Technology 1.0 (PCT 1.0) protocol.

These protocols provide an encrypted connection between a server and a client system. SSL can help protect information when transmitted across public networks such as the Internet. SSL support requires an SSL certificate, which must be installed on a server. For more information about SSL, see Microsoft Knowledge Base Article 245152.

What is PCT?

Private Communication Technology (PCT) is a protocol developed by Microsoft and Visa International for encrypted communication on the Internet. It was developed as an alternative to SSL 2.0. It is similar to SSL. The message formats are similar enough that a server can interact with clients that support SSL as well as clients that support PCT.

PCT is an earlier protocol that has been replaced by SSL 3.0 and is no longer generally used. The Microsoft Secure Sockets Layer (SSL) library supports PCT only for backward compatibility. Most modern programs and servers use SSL 3.0, and PCT is no longer required. For more detailed information, visit the MSDN Library Web site.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

Who could exploit the vulnerability?

Any anonymous attacker who could deliver a specially crafted TCP message to an SSL enabled service on an affected system could attempt to exploit this vulnerability.

How could an attacker exploit this vulnerability?

An attacker could exploit this vulnerability by communicating with an affected system through an SSL enabled service and sending a specially crafted TCP message. Receipt of such a message could cause the affected service on the vulnerable system to fail in such a way that it could execute code.

An attacker could also access the affected component through another vector. For example, an attacker could log on to the system interactively or by using another program that passes parameters to the vulnerable component (locally or remotely).

What systems are primarily at risk from the vulnerability?

All programs that use SSL could be affected. Although SSL is generally associated with Internet Information Services by using HTTPS and port 443, any service that implements SSL on an affected platform is likely to be vulnerable. This includes but is not limited to, Internet Information Services 4.0, Internet Information Services 5.0, Internet Information Services 5.1, Exchange Server 5.5, Exchange Server 2000, Exchange Server 2003, Analysis Services 2000 (included with SQL Server 2000), and any third-party programs that use PCT. SQL Server 2000 is not vulnerable because it specifically blocks PCT connections.

Windows Server 2003 and Internet Information Services 6.0 are only vulnerable to this issue if an administrator has manually enabled PCT (even if SSL has been enabled).

Active Directory domains that have an Enterprise Root certification authority installed are also affected by this vulnerability because Windows 2000 domain controllers will automatically listen for SSL connections.

How is Windows Server 2003 affected?

The way that Windows Server 2003 implements PCT contains the same buffer overrun that is found on other platforms. However, PCT is disabled by default. If the PCT protocol were enabled by using a registry key, Windows Server 2003 could then be vulnerable to this issue. Microsoft is therefore releasing a security update for Windows Server 2003 that corrects the buffer overrun while continuing to leave PCT disabled.

What does the update do?

The update removes the vulnerability by altering the way that the PCT implementation validates the information passed to it and also disables the PCT protocol.

Does this update introduce any behavioral changes?

Yes. While the update does address the vulnerability in PCT, it also disables PCT because this protocol is no longer used and has been replaced by SSL 3.0. This behavior is consistent with the default settings of Windows Server 2003. If administrators require the use of PCT, they can enable it by using the registry key that is described in the Workaround section of this bulletin.

• Only Windows NT 4.0, Windows 2000, and Windows XP systems that are members of a domain are affected by this vulnerability. Windows Server 2003 is not affected by this vulnerability.
• An attacker would require permission to modify user objects in a domain to attempt to exploit this vulnerability. Typically, only members of the Administrators or Account Operators groups would have this permission. However, this permission may have been delegated to other user accounts in the domain.
• Domains typically support auditing of changes to user objects. These audit records could be reviewed to determine which user account may have maliciously modified other user accounts to attempt to exploit this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Reduce the number of users that have account modification permissions.

  To exploit this vulnerability an attacker requires the ability to modify user objects in the domain. Some organizations add user accounts to the Administrators or Account Operators groups unnecessarily. For example, if a Helpdesk representative only requires the ability to reset user passwords, the administrator should directly delegate that permission without adding the representative to the Account Operator group. Reducing the number of user accounts in administrative groups helps block known attack vectors. Only trusted employees should be members of administrative groups. For more information about domain best practices, visit the following Web site.

What is the scope of the vulnerability?

This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

Winlogon reads a value from the domain but does not check the size of this value before inserting it into the allocated buffer.

What is winlogon?

The Windows logon process (Winlogon) is the component of the Windows operating system that provides interactive logon support. Winlogon.exe is the process that manages security-related user interactions in Windows. It handles logon and logoff requests, locking or unlocking the system, changing the password, and other requests. It reads data from the domain during the logon process and uses this data to configure a user’s environment. For more information about Winlogon, visit the MSDN Library Web site.

What is a domain?

A domain can be used to store information about virtually any network object such as printers, file share locations, and personal information. For more information about creating domains using Windows 2000 Server or Windows Server 2003, visit the following Web site.

What could this vulnerability enable an attacker to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

Who could exploit the vulnerability?

An attacker would require permission to modify user objects in a domain to attempt to exploit this vulnerability. Typically, only members of the Administrators or Account Operators groups would have this permission. However, this permission may have been delegated to other user accounts in the domain. User accounts that do not have this permission or anonymous users could not exploit this vulnerability.

How could an attacker exploit this vulnerability?

An attacker could specially modify a value stored in the domain to include malicious data. When this value is passed to an unchecked buffer in Winlogon during the logon process, Winlogon could allow malicious code to be executed.

What systems are primarily at risk from the vulnerability?

Only Windows NT 4.0, Windows 2000, and Windows XP systems that are members of a domain are affected by this vulnerability.

What does the update do?

This update removes the vulnerability by modifying the way the Winlogon process validates the length of a value before passing it to the allocated buffer.

• The vulnerability could only be exploited by an attacker who persuaded a user to open a specially crafted file or to view a directory that contains the specially crafted image. There is no way for an attacker to force a user to open a malicious file.
• In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have no way to force users to visit a malicious Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's site.
• An attacker who successfully exploited this vulnerability could gain the same privileges as the user. Users whose accounts are configured to have fewer privileges on the system would be at less risk than users who operate with administrative privileges.
• Windows Server 2003 is not affected by this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Read e-mail messages in plain text format if you are using Outlook 2002 or later, or Outlook Express 6 SP1 or later, to help protect yourself from the HTML e-mail attack vector.

  Microsoft Outlook 2002 users who have applied Office XP Service Pack 1 or later and Microsoft Outlook Express 6 users who have applied Internet Explorer 6 Service Pack 1 can enable this setting and view all non-digitally signed e-mail messages or non-encrypted e-mail messages in plain text only.

  Digitally signed e-mail messages or encrypted e-mail messages are not affected by the setting and may be read in their original formats. For more information about enabling this setting in Outlook 2002, see Microsoft Knowledge Base Article 307594.

  For information about this setting in Outlook Express 6, see Microsoft Knowledge Base Article 291387.

  Impact of Workaround: E-mail messages that are viewed in plain text format will not contain pictures, specialized fonts, animations, or other rich content. In addition:

  • The changes are applied to the preview pane and open messages.
  • Pictures become attachments so they are not lost.
  • Because the message is still in Rich Text or HTML format in the store, the object model (custom code solutions) may behave unexpectedly.

What is the scope of the vulnerability?

This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

An unchecked buffer in the rendering of Windows Metafile (WMF) and Enhanced Metafile (EMF) image formats.

What are Windows Metafile (WMF) and Enhanced Metafile (EMF) image formats?

A WMF image is a 16-bit metafile format that can contain both vector information and bitmap information. It is optimized for the Windows operating system.

An EMF image is a 32-bit format that can contain both vector information and bitmap information. This format is an improvement over the Windows Metafile Format and contains extended features.

For more information about image types and formats, see Microsoft Knowledge Base Article 320314. Additional information about these file formats is also available at the MSDN Library Web Site.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

How could an attacker exploit this vulnerability?

Any program that renders the affected image types could be vulnerable to this attack. Here are some examples:

• An attacker could host a malicious Web site that is designed to exploit this vulnerability through Internet Explorer 6 and then persuade a user to view the Web site.
• An attacker could also create an HTML e-mail message that has a specially crafted image attached. The specially crafted image could be designed to exploit this vulnerability through Outlook 2002 or Outlook Express 6. An attacker could persuade the user to view the HTML e-mail message.
• An attacker could embed a specially crafted image in an Office document and then persuade the user to view the document.
• An attacker could add a specially crafted image to the local file system or onto a network share and then persuade the user to preview the directory using Windows Explorer in Windows XP.

What systems are primarily at risk from the vulnerability?

The vulnerability could only be exploited on the affected systems by an attacker who persuaded a user to open a specially crafted file or view a directory that contains the specially crafted image. There is no way for an attacker to force a user to open a malicious file.

In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have no way to force users to visit a malicious Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's site.

What does the update do?

The update removes the vulnerability by modifying the way that Windows validates the affected image types.

• In a Web-based attack scenario, an attacker would have to host a Web site that contains a Web page that is used to exploit this vulnerability. An attacker would have no way to force users to visit a malicious Web site. Instead, an attacker would have to persuade them to visit the Web site, typically by getting them to click a link that takes them to the attacker's site.
• By default, Outlook Express 6, Outlook 2002, and Outlook 2003 open HTML e-mail messages in the Restricted sites zone. Additionally, Outlook 98 and Outlook 2000 open HTML e-mail messages in the Restricted sites zone if the Outlook E-mail Security Update has been installed. The Restricted sites zone helps reduce attacks that could attempt to exploit this vulnerability.

  The risk of attack from the HTML e-mail vector can be significantly reduced if you meet all of the following conditions:

  • Apply the update that is included with Microsoft Security Bulletin MS03-040 or a later Cumulative Security Update for Internet Explorer.
  • Use Internet Explorer 6 or later.
  • Use the Microsoft Outlook E-mail Security Update, use Microsoft Outlook Express 6 or later, or use Microsoft Outlook 2000 Service Pack 2 or later in its default configuration.
• An attacker who successfully exploited this vulnerability could gain the same privileges as the user. Users whose accounts are configured to have fewer privileges on the system would be at less risk than users who operate with administrative privileges.
• Windows NT 4.0 and Windows 2000 are not affected by this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Unregister the HCP Protocol.

  To help prevent an attack, unregister the HCP Protocol by deleting the following key from the registry: HKEY_CLASSES_ROOT\HCP. To do so, follow these steps:

  1. Click Start, and then click Run.
  2. Type regedit, and then click OK.

     The registry editor program launches.

  3. Expand HKEY_CLASSES_ROOT, and then highlight the HCP key.
  4. Right-click on the HCP key, and then click Delete.

  Note Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

  Impact of Workaround: Unregistering the HCP protocol will break all local, legitimate help links that use hcp://. For example, links in Control Panel may no longer work.

• Install Outlook E-mail Security Update if you are using Outlook 2000 SP1 or earlier.

  By default, Outlook Express 6, Outlook 2002 and Outlook 2003 open HTML e-mail messages in the Restricted sites zone. Additionally, Outlook 98 and Outlook 2000 open HTML e-mail messages in the Restricted sites zone if the Outlook E-mail Security Update has been installed.

  Customers who use any of these products could be at a reduced risk from an e-mail-borne attack that tries to exploit this vulnerability unless the user clicks a malicious link in the e-mail message.

• Read e-mail messages in plain text format if you are using Outlook 2002 or later, or Outlook Express 6 SP1 or later, to help protect yourself from the HTML e-mail attack vector.

  Microsoft Outlook 2002 users who have applied Office XP Service Pack 1 or later and Microsoft Outlook Express 6 users who have applied Internet Explorer 6 Service Pack 1 can enable this setting and view all non-digitally signed e-mail messages or non-encrypted e-mail messages in plain text only.

  Digitally signed e-mail messages or encrypted e-mail messages are not affected by the setting and may be read in their original formats. For more information about enabling this setting in Outlook 2002, see Microsoft Knowledge Base Article 307594.

  For information about this setting in Outlook Express 6, see Microsoft Knowledge Base Article 291387.

  Impact of Workaround: E-mail messages that are viewed in plain text format will not contain pictures, specialized fonts, animations, or other rich content. In addition:

  • The changes are applied to the preview pane and open messages.
  • Pictures become attachments so they are not lost.
  • Because the message is still in Rich Text or HTML format in the store, the object model (custom code solutions) may behave unexpectedly.

What is the scope of the vulnerability?

This is a remote code execution vulnerability. An attacker who successfully exploited this vulnerability could gain complete control over an affected system. An attacker could take any action on the system, including installing programs, viewing data, changing data, deleting data, or creating new accounts that have full privileges.

What causes the vulnerability?

The process used by the Help and Support Center to validate data inputs.

What is the Help and Support Center?

Help and Support Center (HSC) is a feature in Windows that provides help on a variety of topics. For example, HSC can teach users about Windows features, how to download and install software updates, how to determine whether a particular hardware device is compatible with Windows, and how to receive help from Microsoft. Users and programs can use URL links to Help and Support Center by using the "hcp://" prefix in a URL link instead of “http://”.

What is the HCP protocol?

Similar to the way that the HTTP protocol can use execute URL links to open a Web browser, the HCP protocol can execute URL links to open the Help and Support Center feature.

What is wrong with the Help and Support Center?

An error in input validation occurs.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

How could an attacker exploit this vulnerability?

To exploit this vulnerability, an attacker would have to host a malicious Web site and then persuade a user to view that Web site. An attacker could also create an HTML e-mail message that has a specially crafted link, and then persuade a user to view the HTML e-mail message and then click the malicious link. If the user clicked this link, an Internet Explorer window could open with an HCP URL of the attacker's choice, which could then allow arbitrary code execution.

What systems are primarily at risk from the vulnerability?

Windows XP and Windows Server 2003 contain the affected version of Help and Support Center. Windows NT 4.0 and Windows 2000 are not affected because they do not contain the Help and Support Center.

I am running Internet Explorer on Windows Server 2003. Does Windows Server 2003 mitigate this vulnerability?

No. By default Internet Explorer on Windows Server 2003 runs in a restricted mode that is known as the Internet Explorer Enhanced Security Configuration. However, the HCP protocol is allowed to access the Help and Support Center by default. Therefore, Windows Server 2003 is vulnerable. For more information about Internet Explorer Enhanced Security Configuration, visit the following Web site.

What does the update do?

This update removes the vulnerability by modifying the validation of data passed to the Help and Support Center.

• An attacker must have valid logon credentials to exploit the vulnerability. The vulnerability could not be exploited by anonymous users.
• Windows NT 4.0, Windows XP, and Windows Server 2003 are not affected by this vulnerability. Windows NT 4.0 does not implement the Utility Manager.
• The Windows 2000 Hardening Guide recommends disabling the Utility Manger service. Environments that comply with these guidelines could be at a reduced risk from this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Use Group Policies to disable the Utility Manager on all affected systems that do not require this feature.

  Because the Utility Manager is a possible attack vector, disable it using Group Policies. The Utility Manager process name is Utilman.exe. The following guide provides information about how to require users to run only approved applications using Group Policies.

  Note You may also review the Windows 2000 Hardening Guide. This guide includes information about how to disable the Utility Manager.

  Impact of Workaround:

  The Utility Manager provides easy access to many of the accessibility features of the operating system. This access would be unavailable until the restrictions are removed. To find information about how to manually start many of the accessibility features, visit this Web site.

What is the scope of the vulnerability?

This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

The process used by Utility Manager to launch applications. It is possible that Utility Manager could launch applications with system privileges.

What is Utility Manager?

Utility Manager is an accessibility utility that allows users to check the status of accessibility programs such as Microsoft Magnifier, Narrator, or On-Screen Keyboard, and to start or stop them.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

Who could exploit the vulnerability?

An attacker must be able to log on to the system and then, after starting Utility Manager, run a program that sends a specially crafted message to Utility Manager to attempt to exploit the vulnerability.

How could an attacker exploit this vulnerability?

To exploit this vulnerability, an attacker would first have to start Utility Manager on Windows 2000 and then run a specially designed application that could exploit the vulnerability. In default configurations of Window 2000, Utility Manager is installed but is not running. This vulnerability could allow an attacker to gain complete control over a Windows 2000 system.

What systems are primarily at risk from the vulnerability?

Only Windows 2000 is affected by this vulnerability. Workstations and terminal servers that are based on Windows 2000 are primarily at risk. Servers are only at risk if users who do not have sufficient administrative credentials are given the ability to log on to servers and to run programs. However, best practices strongly discourage allowing this.

I am using Windows 2000, but I am not using Utility Manager or any of the accessibility features. Am I still vulnerable?

Yes. By default, Utility Manager is installed and enabled. However, Utility Manager is not running by default.

Could the vulnerability be exploited over the Internet?

No. An attacker must be able to log on to the specific system targeted for attack. An attacker cannot load and run a program remotely using this vulnerability.

What does the update do?

This update removes the vulnerability by modifying the way that Utility Manager launches applications.

• An attacker must have valid logon credentials to exploit the vulnerability. The vulnerability could not be exploited by an anonymous user.
• Windows NT 4.0, Windows 2000, and Windows Server 2003 are not affected by this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

Delete the affected Windows Management Interface Provider.

An administrator with local administrative permissions can delete the affected Windows Management Interface (WMI) Provider by inserting the following script into a text file that has a ‘.vbs’ file name extension and then running it.

To delete the affected WMI Provider:

set osvc = getobject("winmgmts:root\cimv2")
set otrigger = osvc.get("__win32provider='cmdtriggerconsumer'")
otrigger.delete_

The installation of the update automatically re-registers the affected WMI Provider that is referenced above. You do not have to take any additional steps to restore the system to typical functionality after the update has been applied.

Impact of Workaround: Tasks that are created as event-based triggers will not function while this provider is not registered. For more information about event-based triggers, visit the following Web site.

Note In rare cases, Windows XP could re-register this WMI Provider. For example, if Windows XP detects that the WMI repository has become corrupted, it could try to re-register the affected WMI Provider.

What is the scope of the vulnerability?

This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

Under special conditions, a non-privileged user of Microsoft Windows XP could create a task that could execute with system permissions.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

How could an attacker exploit this vulnerability?

To exploit the vulnerability, an attacker must be able to log on to the system and create a task. Because an attacker must have valid logon credentials to exploit the vulnerability, remote systems are not at risk.

What systems are primarily at risk from the vulnerability?

Only Windows XP is affected by this vulnerability.

What does the update do?

The update removes the vulnerability by preventing users from creating tasks at an elevated level of privilege.

Does this update contain any other behavioral changes?

Yes. This update also includes several changes in functionality, documented below:

• Before this update, a user could sometimes create event-based triggers by using the Eventtriggers.exe command-line tool without having to supply a user name and password. After this update has been installed, a user may have to supply a valid user name and password to create event-based-triggers using Eventttrigers.exe. For detailed information about the Eventtriggers.exe command-line options, visit the following Web site.
• Previously, administrators could create event-based triggers with the Task Scheduler service stopped or disabled. Now, the Task Scheduler service must be running. For more information about Task Scheduler, visit the following Web site.
• A new limit of 1,000 triggers has also been established as part of this update. Existing event-based triggers over this limit will continue to function after the update has been installed. However, no additional event-based triggers may be created.
• Permissions have been strengthened on event-based triggers that are created after the update has been installed.

• An attacker must have valid logon credentials and be able to logon locally to exploit this vulnerability. It could not be exploited remotely.
• Windows XP and Windows Server 2003 are not affected by this vulnerability.

None.

What is the scope of the vulnerability?

This is a privilege elevation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

The programming interface that is used to create entries in the LDT. These entries contain information about segments of memory. An attacker could create a malicious entry to gain access to protected kernel memory.

What is the Local Descriptor Table?

The Local Descriptor Table (LDT) contains entries called descriptors. These descriptors contain information that defines a particular segment of memory.

What is wrong with the way that a descriptor entry can be created in the LDT?

The programming interface should not allow programs to create descriptor entries in the LDT that point to areas of protected memory.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited the vulnerability could take complete control of the affected system. An attacker could take any action on the system, including installing programs, viewing data, changing data, deleting data, or creating new accounts that have full privileges.

Who could exploit the vulnerability?

An attacker must be able to log on locally to the system and run a program to exploit this vulnerability.

How could an attacker exploit this vulnerability?

To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially designed program that could exploit the vulnerability and potentially gain complete control over the affected system.

What systems are primarily at risk from the vulnerability?

Workstations and terminal servers are primarily at risk. Servers are only at risk if users who do not have sufficient administrative credentials are given the ability to log on and to run programs. However, best practices strongly discourage allowing this.

Could the vulnerability be exploited over the Internet?

No. An attacker must be able to log on to the specific system targeted for attack. An attacker cannot load and run a program remotely using this vulnerability.

What does the update do?

The update removes the vulnerability by modifying the way descriptors entries are created in the LDT.

• In the most common scenarios, NetMeeting (which uses H.323) must be running to become vulnerable.
• In the most common scenarios, systems that use Internet Connection Firewall (ICF) and that do not run any H.323-based applications are not vulnerable.
• Windows NT 4.0 is not affected by this vulnerability unless the stand-alone version of NetMeeting has been manually installed by an administrator.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Block ports TCP 1720 and TCP 1503 both inbound and outbound at the firewall.

  Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed. Microsoft recommends blocking all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports.

  Impact of Workaround:

  If inbound and outbound TCP ports 1503 and 1720 are blocked, users will not be able to connect to the Internet Locator Service (ILS) or to other NetMeeting clients.

What is the scope of the vulnerability?

This is a buffer overrun vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

Unchecked buffers in Microsoft’s H.323 implementation.

What is H.323?

H.323 is an ITU standard that specifies how PCs, equipment, and services for multimedia communicate over networks that do not provide a guaranteed level of service, such as the Internet. H.323 terminals and equipment can carry real-time video, voice, data, or any combination of these elements. Products that use H.323 for audio and video let users connect and communicate with other people over the Internet, just as people using different makes and models of telephones can communicate using the telephone.

What affected applications use the H.323 protocol?

The H.323 protocol is implemented in a number of Microsoft applications and operating system components. This issue may affect systems that have one or more of the following services or applications running:

• Telephony Application Programming Interface (TAPI)-based applications
• NetMeeting
• Internet Connection Firewall (ICF)
• Internet Connection Sharing
• The Microsoft Routing and Remote Access service

What is TAPI?

Windows Telephony Applications Programming Interface (TAPI) is a part of the Windows Open System Architecture. By using TAPI, developers can create telephony applications. TAPI is an open industry standard, defined with significant and ongoing input from the worldwide telephony and computing community. Because TAPI is hardware-independent, compatible applications can run on a variety of PC and telephony hardware and can support a variety of network services. TAPI implements the H.323 protocol. Applications that use TAPI could be vulnerable to the issue that is described in this bulletin.

Are any TAPI-based H.323 applications installed by default on any of the affected systems?

Microsoft Phone Dialer is the only H.323 TAPI-based application that is installed by default on Windows 2000 and Windows XP. Third-party applications could enable and use the H.323 functionality in TAPI.

Note Microsoft Phone Dialer is not included in Windows Server 2003.

What is NetMeeting?

NetMeeting delivers a complete Internet and enterprise conferencing solution for all users of Windows, with multipoint data conferencing, text chat, whiteboard, and file transfer, and point-to-point audio and video. NetMeeting implements the H.323 protocol and is installed by default, but is not running by default, on all affected systems.

If I am running NetMeeting but I am not running Internet Connection Sharing, ICF, or the Routing and Remote Access service. Am I vulnerable?

Yes. When you are running NetMeeting, you are vulnerable to this issue.

If I am running NetMeeting but I am not connected to an ILS server or in a peer-to-peer NetMeeting session, am I vulnerable?

Yes, unless TCP ports 1720 and 1503 are blocked on the system.

If I have never installed the stand-alone version of NetMeeting, am I vulnerable?

NetMeeting was included as part of Windows 2000, Windows XP, and Windows Server 2003. This update addresses the versions of NetMeeting that were included with these operating systems. NetMeeting is also available as a stand-alone download for other operating systems and as part of other applications, which could also be vulnerable to this issue. If you have installed the stand-alone version of NetMeeting, install an updated version that addresses this vulnerability. To download the updated version, visit the following Web site. The updated version that addresses this vulnerability is Version 3.01 (4.4.3399).

Are Windows 98, Windows 98 Second Edition, or Windows Millennium Edition critically affected by this vulnerability?

No. Although these operating systems may contain NetMeeting, the vulnerability is not critical on these operating systems. As a method of addressing this vulnerability, you can download and install the stand-alone version of NetMeeting for these operating systems from the following Web site. For more information about severity ratings, visit the following Web site.

What is Internet Connection Firewall?

Internet Connection Firewall (ICF) provides basic intrusion-prevention functionality to systems that run either Windows XP or Windows Server 2003. It is designed for systems that are directly connected to a public network or systems that are part of a home network when used with Internet Connection Sharing.

If I am running only Internet Connection Firewall on Windows XP or on Windows Server 2003, am I vulnerable?

No, not automatically. However, if you use NetMeeting, even with ICF running, you could be vulnerable to this issue. NetMeeting opens ports in ICF that could expose this vulnerability.

Manually opening TCP ports 1720 and 1503 could also expose this vulnerability. Third-party applications may also cause ICF to open ports in response to H.323 communication.

What is Internet Connection Sharing?

By using Internet Connection Sharing users can connect one system to the Internet and share Internet service with several other systems on a home or small office network. The Network Setup Wizard in Windows XP automatically provides all the network settings that are necessary to share one Internet connection with all the systems in a network. Each system can use programs such as Internet Explorer and Outlook Express as if the system were directly connected to the Internet.

Internet Connection Sharing is a feature of Windows 2000, Windows XP, and Windows Server 2003 but is not enabled by default on any of the affected systems.

If I have enabled Internet Connection Sharing, but I have not enabled Internet Connection Firewall, am I vulnerable?

Yes, Internet Connection Sharing enables the ports that could allow a system to become vulnerable to this issue.

If ICF and Internet Connection Sharing are running, this attack could not occur unless the user was also using NetMeeting, or had manually opened port 1503 or port 1720.

What is the Microsoft Routing and Remote Access service?

The Microsoft Routing and Remote Access service makes it possible for a system that is running Windows 2000 Server or the Windows Server 2003 to function as a network router. Remote access allows users who have remote systems to create a logical connection to an organization’s network or to the Internet. The Microsoft Routing and Remote Access service supports H.323 requests that are routed either to or from a network.

If I am running the Microsoft Routing and Remote Access service on Windows 2000, am I vulnerable?

Yes. By default, Windows 2000 uses the Microsoft Routing and Remote Access service with Network Address Translation (NAT) functionality, which exposes the vulnerability. However, an administrator can disable the H.323 functionality by using the netsh command. Detailed steps are outlined in Microsoft Knowledge Base Article 838834.

Note If a system is configured to run another Microsoft Routing and Remote Access service without NAT (for example, Virtual Private Network, OSPF, or Routing Information Protocol), it would not be affected by this vulnerability.

If I am running the Microsoft Routing and Remote Access service on Windows Server 2003, am I vulnerable?

No. By default, Windows Server 2003 Routing and Remote Access service does not enable the H.323 functionality. However, an administrator could enable the H.323 functionality and then expose the system to this vulnerability.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

Who could exploit the vulnerability?

Any anonymous user who could deliver a specially crafted H.323 request to any of the above affected systems.

How could an attacker exploit this vulnerability?

An attacker could attempt to exploit the vulnerability by locating users running NetMeeting, an H.323-based TAPI program, or both.

An attacker could also attempt to exploit the vulnerability through Internet Connection Sharing by remotely executing code on systems that have Internet Connection Sharing enabled. If ICF and Internet Connection sharing are running, this attack would not be possible unless the user was also using NetMeeting.

What systems are primarily at risk from the vulnerability?

Systems that are running NetMeeting or that are running an H.323-based program.

What does the update do?

The update modifies the way that the affected systems process the specially crafted H.323 requests.

• An attacker must have valid logon credentials and be able to logon locally to exploit this vulnerability. It could not be exploited remotely.
• Windows XP and Windows Server 2003 are not affected by this vulnerability.

None.

What is the scope of the vulnerability?

This is a privilege evaluation vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges. To exploit the vulnerability, an attacker must be able to log on locally to the system and run a program.

What causes the vulnerability?

The operating system component that handles the VDM subsystem could be used to gain access to protected kernel memory. In certain circumstances, some privileged operating system functions might not validate system structures and could allow an attacker to execute malicious code with system privileges.

What is the Virtual DOS Machine subsystem?

A Virtual DOS Machine (VDM) is a environment that emulates MS-DOS and DOS-based Windows in Windows NT-based operating systems. A VDM is created whenever a user starts an MS-DOS application on a Windows NT-based operating system.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

Who could exploit the vulnerability?

To exploit the vulnerability, an attacker must be able to log on locally to a system and run a program.

How could an attacker exploit this vulnerability?

To exploit this vulnerability, an attacker would first have to log on to the system. An attacker could then run a specially-designed application that could exploit the vulnerability, and thereby gain complete control over the affected system.

What systems are primarily at risk from the vulnerability?

Workstations and terminal servers are primarily at risk. Servers are only at risk if users who do not have sufficient administrative credentials are given the ability to log on to servers and to run programs. However, best practices strongly discourage allowing this.

Could the vulnerability be exploited over the Internet?

No. An attacker must be able to log on to the specific system targeted for attack. An attacker cannot load and run a program remotely by using this vulnerability.

What does the update do?

This update modifies the way that Windows validates data when referencing memory locations that are allocated to a VDM.

• In the most common scenarios, this vulnerability is a denial of service vulnerability.
• The Negotiate SSP interface is also enabled by default in Internet Information Services (IIS). However, only Windows 2000 (IIS 5.0) and Windows Server 2003 Web Server Edition (IIS 6.0) install Internet Information Services (IIS) by default.
• Windows NT 4.0 is not affected by this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Workarounds for the Internet Information Services Attack Vector
  • Disable Integrated Windows Authentication

    Administrators can help reduce the risk of attack through Internet Information Services by disabling Integrated Windows Authentication. Information about how to enable or disable this option is available at the following Web site.

    Impact of Workaround: Any IIS-based applications that require Windows NT Challenge/Response authentication (NTLM) or Kerberos authentication will no longer function correctly.

  • Disable the Negotiate SSP

    Administrators can disable just the Negotiate SSP (which keeps NTLM enabled) by following the instructions in Microsoft Knowledge Base Article 215383, which is summarized below:

    To disable Negotiate (and therefore prevent Kerberos authentication), use the following command . Notice that “NTLM” must be uppercase to avoid any adverse effects):

    cscript adsutil.vbs set w3svc/NTAuthenticationProviders “NTLM”

    Impact of Workaround: Any IIS-based applications that require Kerberos authentication will no longer function correctly.

What is the scope of the vulnerability?

This is a buffer overrun vulnerability. However, it is most likely a denial of service vulnerability. An attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

An unchecked buffer in the Negotiate SSP interface.

What is the Negotiate Security Support Provided Interface?

Because Windows supports many different types of authentication, the authentication method used when a client connects to a server must be negotiated. The Negotiate SSP Interface is the operating system component that provides this functionality. It is based on the Simple and Protected GSS-API Negotiate Mechanism (SPNEGO) that is defined in RFC 2478. For more information about Windows authentication methods, visit the following Web site.

Why is Internet Information Services affected?

The Negotiate SSP Interface is also enabled by default in Internet Information Services (IIS) so that IIS can use authentication protocols such as NTLM or Kerberos to provide secure access to resources. For more information about the methods of authentication supported by IIS, visit the following Web site.

What might an attacker use the vulnerability to do?

Although it is most likely that only a denial of service would result, an attacker who successfully exploited this vulnerability could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges. If an attacker caused the affected system to become unresponsive, an administrator could restore normal functionality by restarting the affected system. However, the system could remain susceptible to a new denial of service attack until the update was applied.

Who could exploit the vulnerability?

Any anonymous user who could deliver a specially crafted message to an affected system could attempt to exploit this vulnerability. Because this feature is enabled by default on all affected systems, any user who could establish a connection with an affected system could attempt to exploit this vulnerability.

How could an attacker exploit this vulnerability?

An attacker could exploit this vulnerability by creating a specially crafted network message and sending the message to the affected system.

An attacker could also access the affected component through another vector. For example, an attacker could log on to the system interactively or by using another program that passes parameters to the vulnerable component (locally or remotely).

What systems are primarily at risk from the vulnerability?

All affected systems could be vulnerable to this issue by default. Furthermore, by default, systems that are running Internet Information Services 5.0, Internet Information Services 5.1, and Internet Information Services 6.0 are also vulnerable to this issue through any listening port.

What does the update do?

The update removes the vulnerability by modifying the way that the Negotiate SSP Interface validates the length of a message before passing the message to the allocated buffer.

• Only systems that have enabled SSL are affected, typically only server systems. SSL support is not enabled by default on any of the affected systems. However, SSL is generally used on Web servers to support electronic commerce programs, online banking, and other programs that require secure communications.
• Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.
• Windows NT 4.0 is not affected by this vulnerability.

Microsoft has tested the following workarounds. While these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified below.

• Block ports 443 and 636 at the firewall

  Port 443 is used to receive SSL traffic. Port 636 is used for LDAP SSL connections (LDAPS). Blocking them at the firewall will help prevent systems that are behind that firewall from attempts to exploit this vulnerability. Other ports may be found that could be used to exploit this vulnerability. However, the ports listed here are the most common attack vectors. Microsoft recommends blocking all unsolicited inbound communication from the Internet to help prevent attacks that may use other ports.

  Impact of Workaround: If ports 443 or 636 are blocked, the affected systems can no longer accept external connections using SSL or LDAPS.

What is the scope of the vulnerability?

A denial of service vulnerability in the Microsoft Secure Sockets Layer (SSL) library affects how it handles specially crafted SSL messages. This vulnerability could cause the affected system to stop accepting SSL connections in Windows 2000 and in Windows XP. The vulnerability in Windows Server 2003 could cause the affected system to automatically restart.

Note that the denial of service vulnerability would not allow attackers to execute code or elevate their privileges, but it could cause the affected system to stop accepting requests.

What causes the vulnerability?

The process used by the SSL Library to check message inputs.

What is the Microsoft Secure Sockets Layer library?

The Microsoft Secure Sockets Layer library contains support for a number of secure communication protocols. These include Transport Layer Security 1.0 (TLS 1.0), Secure Sockets Layer 3.0 (SSL 3.0), the older and seldom-used Secure Sockets Layer 2.0 (SSL 2.0), and Private Communication Technology 1.0 (PCT 1.0) protocol.

These protocols provide an encrypted connection between a server and a client system. SSL can help protect information when users connect across public networks such as the Internet. SSL support requires an SSL certificate, which must be installed on a server. For more information about SSL, see Microsoft Knowledge Base Article 245152.

What might an attacker use the vulnerability to do?

In Windows 2000 and Windows XP, an attacker who successfully exploited this vulnerability could cause an affected system to stop accepting SSL connections. In Windows Server 2003, an attacker could cause the affected system to automatically restart. During that time, the affected system would not be able to respond to authentication requests. After restart, the affected system would be restored to typical functionality. However, it would still be susceptible to a new denial of service attack unless the update is applied.

If an attacker exploits this vulnerability, a system error event may be recorded. The event ID 5000 may be recorded in the System event log, with the SymbolicName value of "SPMEVENT_PACKAGE_FAULT" and the following description:

"The security package NAME generated an exception", Where NAME contains the value of "Schannel" or "Microsoft Unified Security Protocol Provider."

Who could exploit the vulnerability?

Any anonymous user who could deliver a specially crafted SSL message to an affected system could attempt to exploit this vulnerability.

How could an attacker exploit this vulnerability?

An attacker could exploit this vulnerability by creating a program that could communicate with a vulnerable server through an SSL-enabled service to send a specific kind of specially crafted TCP message. Receipt of such a message could cause the vulnerable system to fail in such a way that it could cause a denial of service.

An attacker could also access the affected component through another vector. For example, an attacker could log on to the system interactively or by using another program that passes parameters to the vulnerable component (locally or remotely).

What systems are primarily at risk from the vulnerability?

All systems that have SSL enabled are vulnerable. Although SSL is generally associated with Internet Information Services by using HTTPS and port 443, any service that implements SSL on an affected platform is likely to be vulnerable. This includes but is not limited to Internet Information Services 4.0, Internet Information Services 5.0, Internet Information Services 5.1, Exchange Server 5.5, Exchange Server 2000, Exchange Server 2003, Analysis Services 2000 (included with SQL Server 2000), and any third-party programs that use SSL.

Windows 2000 domain controllers that are installed in an Active Directory domain that also has an Enterprise Root certification authority installed are affected by this vulnerability because they automatically listen for secure SSL connections.

What does the update do?

The update removes the vulnerability by modifying the handling of specially crafted SSL messages.

• Because of the unique layout of the memory structures on each affected system, exploiting this vulnerability on a mass scale could potentially be difficult.

None.

What is the scope of the vulnerability?

While potentially a remote code execution vulnerability, this is most likely a denial of service vulnerability. However, an attacker who successfully exploited this vulnerability to allow code execution could gain complete control over an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

What causes the vulnerability?

A potential "double-free" condition exists that could lead to memory corruption in the Microsoft ASN.1 Library.

What is a “double free” condition?

An attacker could cause an affected system, while processing a specially crafted message, to try to release or “free” memory that may have been set aside for use multiple times. Releasing memory that has already been freed could lead to memory corruption. An attacker could add arbitrary code to memory that is then executed when the corruption occurs. This code could then be executed at a system level of privilege.

Typically, this vulnerability will cause a denial of service to occur. However, on a limited basis, code execution could occur. Because of the unique layout of the memory on each affected system, exploiting this vulnerability on a mass scale could potentially be difficult.

What is ASN.1?

Abstract Syntax Notation 1 (ASN.1) is a language that is used to define standards. It is used by many applications and devices in the technology industry to allow data exchange across various platforms. ASN.1 has no direct relationship to any specific standard, encoding method, programming language, or hardware platform. For more information about ASN.1, see Microsoft Knowledge Base Article 252648.

What might an attacker use the vulnerability to do?

An attacker who successfully exploited this vulnerability to allow code execution could take complete control of an affected system, including installing programs; viewing, changing, or deleting data; or creating new accounts that have full privileges.

In the most likely scenario, an attacker could cause a denial of service condition. An administrator could restart the affected system to restore typical functionality.

How could an attacker exploit this vulnerability?

Because ASN.1 is a standard for many applications and devices, there are many potential attack vectors. To successfully exploit this vulnerability, an attacker must force a system to decode specially crafted ASN.1 data. For example, by using authentication protocols that are based on ASN.1, an attacker could construct a specially crafted authentication request that could expose this vulnerability.

What systems are primarily at risk from this vulnerability?

Server systems are at greater risk than client systems because they are more likely to have a server process running that decodes ASN.1 data.

Are Windows 98, Windows 98 Second Edition, or Windows Millennium Edition critically affected by this vulnerability?

No. Although Windows Millennium Edition does contain the affected component, the vulnerability is not critical. For more information on severity ratings, visit the following Web site.

What does the update do?

The update removes the vulnerability by modifying the handling of specially crafted data by the ASN.1 Library.

How does this vulnerability relate to the vulnerability corrected by MS04-007?

Both vulnerabilities were in the ASN.1 component. However, this update corrects a newly reported vulnerability that was not addressed as part of MS04-007. MS04-007 fully protects against the vulnerabilities discussed in that bulletin, but this update includes all the updates provided in MS04-007 and replaces it. If you install this update, you do not need to install MS04-007.