Export (0) Print
Expand All

Microsoft Security Bulletin MS02-070 - Moderate

Flaw in SMB Signing Could Enable Group Policy to be Modified (329170)

Published: December 11, 2002 | Updated: January 22, 2003

Version: 2.0

Originally posted: December 11, 2002
Updated: January 22, 2003

Summary

Who should read this bulletin:
System administrators using Microsoft® Windows® XP or Windows 2000, the latter especially in a domain controller role.

Impact of vulnerability:
Modify group policy.

Maximum Severity Rating:
Moderate

Recommendation:
Administrators whose Windows 2000 or Windows XP systems that are configured to use SMB Signing should install the patch immediately.

Affected Software:

  • Microsoft Windows 2000
  • Microsoft Windows XP

End User Bulletin:
An end user version of this bulletin is available at: http://www.microsoft.com/athome/security/update/bulletins/default.mspx

General Information

Technical description:

Subsequent to releasing this bulletin it was determined that the fix that eliminates the vulnerability was not included in Microsoft Windows XP Service Pack 1. The bulletin has been updated to reflect this fact, and the patch has been updated so that it installs on Windows XP Service Pack 1 systems. Customers who are currently running XP Service Pack 1 with SMB signing enabled should apply the patch.

Server Message Block (SMB) is a protocol natively supported by all versions of Windows. Although nominally a file-sharing protocol, it is used for other purposes as well, the most important of which is disseminating group policy information from domain controllers to newly logged on systems. Beginning with Windows 2000, it is possible to improve the integrity of SMB sessions by digitally signing all packets in a session. Windows 2000 and Windows XP can be configured to always sign, never sign, or sign only if the other party requires it.

A flaw in the implementation of SMB Signing in Windows 2000 and Windows XP could enable an attacker to silently downgrade the SMB Signing settings on an affected system. To do this, the attacker would need access to the session negotiation data as it was exchanged between a client and server, and would need to modify the data in a way that exploits the flaw. This would cause either or both systems to send unsigned data regardless of the signing policy the administrator had set. After having downgraded the signing setting, the attacker could continue to monitor the session and change data within it; the lack of signing would prevent the communicants from detecting the changes.

Although this vulnerability could be exploited to expose any SMB session to tampering, the most serious case would involve changing group policy information as it was being disseminated from a Windows 2000 domain controller to a newly logged-on network client. By doing this, the attacker could take actions such as adding users to the local Administrators group or installing and running code of his or her choice on the system.

Mitigating factors:

  • Exploiting the vulnerability would require the attacker to have significant network access already. In most cases, the attacker would need to be located on the same network segment as one of the two participants in the SMB session.
  • The attacker would need to exploit the vulnerability separately for each SMB session he or she wanted to interfere with.
  • The vulnerability would not enable the attacker to change group policy on the domain controller, only to change it as it flowed to the client.
  • SMB Signing is disabled by default on Windows 2000 and Windows XP because of the performance penalty it exacts. On networks where SMB Signing has not been enabled, the vulnerability would pose no additional risk - because SMB data would already be vulnerable to modification.

Severity Rating:

ProductSeverity
Windows 2000 Moderate
Windows XP Low

The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. The threat to Windows XP systems is lower than for Windows 2000 systems because the most serious potential outcome of exploiting the vulnerability - modifying group policy as it is disseminated by a domain controller - does not apply to Windows XP, since it cannot serve in such a function.

Vulnerability identifier: CAN-2002-1256

Tested Versions:

Microsoft tested Windows 2000 and Windows XP to assess whether they are affected by this vulnerability. SMB Signing was not available in previous versions of Windows.

What's the scope of the vulnerability?
This vulnerability could provide a means by which a communications channel that is ostensibly cryptographically protected could in reality be unprotected. In the most serious case, exploiting the vulnerability could enable an attacker to change security policy information as it flowed from a Windows 2000 domain controller to a newly logged on system, thereby gaining the ability to take actions such as installing and running programs on the system.
Exploiting the vulnerability would require the attacker to not only have access to the network's communications media, but to also have a favorable location within the network. In addition, the attacker would need to exploit the vulnerability separately for every communications session he or she wanted to modify.

What causes the vulnerability? 
The vulnerability results because of an error in the Windows 2000 and Windows XP implementations of the SMB signing function that could cause signing to not be done even when it's configured to always be required.

What is SMB? 
SMB (Server Message Block) is a file-sharing protocol that is natively supported in all versions of Windows. SMB (and its follow-on, Common Internet File System) allows users and computers to efficiently locate and access files on other systems, and work with the data in them without creating conflicts with other users.

What is SMB signing? 
SMB signing is a feature available in Windows 2000 and Windows XP, through which all communications using the Server Message Block (SMB) protocol can be digitally signed at the packet level. Digitally signing the packets enables the recipient of the packets to confirm their point of origination and their authenticity - that is, that they came from the expected location and haven't been tampered with in transit.

Why would someone want to digitally sign SMB traffic? 
The most straightforward reason is that a user might want to ensure that any files he or she retrieves from, for instance, a file server haven't been altered in transit by an attacker on the network. But there's a more pressing reason. Windows domains use SMB to transfer some types of security related information. For instance, when a workstation logs onto a domain, the domain controller sends group policy information to the workstation via SMB. Signing provides a way to ensure that the workstation is receiving bona fide group policy.

How is SMB Signing configured? 
SMB Signing is configured via local policy settings (specifically, Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options). There are four settings available: two govern how the system operates when acting as a client, and two govern how it operates when acting as a server. In each case, the system can be configured to allow, disallow, or require signing. The system defaults for both Windows 2000 and Windows XP enable signing but do not require it.

What's wrong with the way SMB Signing is implemented? 
There's a flaw in the way Windows 2000 and Windows XP respond in the case where a system has been configured to require signing. By design, when a Windows 2000 or Windows XP system establishes an SMB session with another system, it carries out a negotiation to determine what the other system's signing requirements are. If the other system can't or won't meet its needs (for instance, if a Windows XP system were configured to require signing but the other system was configured never to sign SMB data), it should refuse to establish the communications channel.
A security vulnerability results because, if the negotiation information were malformed in a particular way, a Windows 2000 or Windows XP system that had been configured to require signing could instead silently drop the requirement, and engage in unsigned communications despite the local policy settings.

What could an attacker do via this vulnerability? 
An attacker could use this vulnerability to cause SMB signing on a Windows 2000 or Windows XP system to be silently disabled for the duration of an SMB session, with the result that the subsequently transmitted data would be unsigned. This would enable anyone who could access the data to modify it as it transited the network.
All SMB sessions, whether used to transfer files, group policy, or some other information, could be affected by the vulnerability. However, it would pose the greatest risk in the case of group policy - specifically, where a Windows 2000 domain controller had been configured to require SMB signing, as a way of ensuring the authenticity of the group policy settings it downloads to domain members. By exploiting the vulnerability and then subsequently changing the group policy data as it was sent from the domain controller to a client, the attacker could change the policy settings that the client received.

What would be the effect of changing the group policy settings? 
It would depend on the specific changes. However, group policy is a powerful technology through which much of the behavior of Windows systems can be controlled. For instance, group policy can be used to change permissions on folders and files, download and run programs at system startup, and take other actions.

Would the attacker be able to use the vulnerability to gain administrative privileges on the domain? 
No. Domain group memberships are held at the domain controller, not the client. Changing the group policy that's downloaded to the client wouldn't allow the attacker to change his or her domain group memberships. On the other hand, the attacker could use the vulnerability to change the group memberships on the local machine and, for instance, add users to the local Administrators group.

Who could exploit the vulnerability? 
In order to exploit the vulnerability, the attacker would need to already have a significant degree of access to communications on the network. He or she would need to be able to monitor and modify the communications between the two systems in real-time. This would typically require the attacker to not only have physical access to the network media, but a favorable location within the network as well.

What do you mean "a favorable location within the network"? 
It wouldn't be enough for the attacker to have access to the network media. He or she would also have to be located along the path taken by the data as it passed between the client and the server. The vulnerability provides no way for the attacker to force the communications to take a particular path so, in most cases, he or she would need to be located on the same network segment as one of the two communicants.

Could the attacker change group policy on a system that was already logged onto the domain? 
No. The opportunity to impose new policy would occur when a new system logged onto the domain. If the attacker missed the opportunity, he or she would need to wait until the next time the system logged on.

Would exploiting the vulnerability once permanently disable SMB signing? 
No. The attacker would need to exploit the vulnerability separately for each communications session that he or she wanted to interfere in.

Could the attacker change the group policy on the Windows 2000 domain controller? 
No. The vulnerability would only allow the attacker to change the data received by the client. It would not provide any way to change the data as it resides on the server.

Why have you discussed the domain controller scenario only in the context of Windows 2000? 
Windows XP cannot be used as a domain controller. As a result, this scenario - which is the highest-risk scenario associated with the vulnerability - doesn't apply to Windows XP.

I heard that Windows XP clients can inadvertently trigger the vulnerability. Is this true? 
Yes. Windows XP Service Pack 1 contained a regression error that adds information to the negotiation information it sends. This information can trigger the vulnerability, and cause systems running Windows XP Gold or Windows 2000 to drop SMB signing. A fix is available to eliminate this regression error.
It is important to understand two critical points regarding the regression error in Windows XP Service Pack 1:

  • The regression error poses no security threat to Windows XP Service Pack 1 systems. Instead, it poses an availability risk. Consider a scenario where both a Windows XP SP1 system and a Windows 2000 domain controller were configured to require signing. The regression could cause the Windows 2000 system to downgrade its signing, which the Windows XP SP1 system would then reject. The result would be that the communications couldn't occur.
  • Installing the fix for the regression error in Windows XP doesn't eliminate the vulnerability. The vulnerability lies in Windows XP Gold and Windows 2000; the regression error simply triggers it in some cases. If you apply the security patch to all Windows XP Gold and Windows 2000 systems that require signing, it doesn't matter whether you apply the regression fix to your Windows XP SP1 systems - if no systems on the network have the vulnerability, it doesn't matter whether there are systems that could inadvertently trigger it.

You've mentioned this "regression patch" in the previous question, but I'm still unsure if I need to be concerned or not?
In short, if you have applied the security patch offered in this bulletin to all Windows 2000 and Windows XP machines on your network, you do not need to be concerned about applying the regression patch. Customers only need to be concerned about applying the regression patch mentioned if they choose not to install this patch or are running Windows XP Service Pack 1 in a server role for file sharing and require SMB signing.

Why isn't the "regression patch" included as part of the patch released with this bulletin?
Because the regression introduced in Windows XP Service Pack 1 is not a security vulnerability, the fix for this unlikely behavior is described in Microsoft Knowledge Base article 810907 and is available through Microsoft Product Support Services. It is only recommended for customers who are directly experiencing this problem. Information on how to contact Microsoft Product Support Services is available by following the URL provided in the "Other Information" section of this bulletin.

Should I apply the patch to every Windows 2000 or Windows XP system? 
You can, but it only makes sense to install it on systems that are configured to require SMB Signing, or that communicate with systems that do.

Is SMB signing required by default? 
No. There is a performance penalty associated with SMB signing, and as a result it is not required in default configurations of Windows 2000 or Windows XP.

SMB signing isn't enabled on my systems. Am I at any risk from this vulnerability? 
If SMB signing isn't enabled, your network is at no increased risk because of this vulnerability. That is, if signing is disabled, an attacker could already modify the SMB data stream.

How does the patch address the vulnerability? 
The patch causes Windows 2000 and Windows XP to correctly handle negotiation sessions that contain the type of malformed information discussed above.

Download locations for this patch

Microsoft Windows 2000:

Microsoft Windows XP:

Additional information about this patch

Installation platforms:

  • The Windows 2000 patch can be installed on systems running Windows 2000 Service Pack 2 or Service Pack 3.
  • The Windows XP patch can be installed on systems running Windows XP Gold or Windows XP Service Pack 1.

Inclusion in future service packs:

The fix for this issue will be included in Windows 2000 Service Pack 4 and Windows XP Service Pack 2.

Reboot needed: Yes

Patch can be uninstalled: Yes

Superseded patches: None.

Verifying patch installation:

Windows 2000:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q329170

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SP4\Q329170\Filelist

Windows XP:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q329170

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP1\Q329170\Filelist

Windows XP Service Pack 1:

  • To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\Q329170

  • To verify the individual files, use the date/time and version information provided in the following registry key:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\Q329170\Filelist

Caveats:

None

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

Obtaining other security patches:

Patches for other security issues are available from the following locations:

  • Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
  • Patches for consumer platforms are available from the WindowsUpdate web site

Other information:

Support:

  • Microsoft Knowledge Base article 329170 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
  • Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.

Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.

Disclaimer:

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

Revisions:

  • V1.0 (December 11, 2002): Bulletin Created.
  • V1.1 (December 19, 2002): Updated Registry Key information in Verifying Patch Installation section
  • V2.0 (January 22, 2003): Subsequent to the release of this bulletin, it was determined that the fix described here was not included in XP Service Pack 1. The bulletin and patch have been updated to reflect this.

Built at 2014-04-18T13:49:36Z-07:00

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2015 Microsoft