Post-SP3 FRS Update Polishes Performance; and First 2003 Security Hotfix

It's time for another File Replication Service (FRS) performance boost. Microsoft released a standalone FRS update before the release of Windows 2000 Service Pack 3 (SP3) and bundled the update in SP3. Last week, the company issued a post-SP3 FRS tune-up that addresses several inefficiencies in the original replication model. For reference purposes, a full replication is also known as version vector join (vvjoin). Of the eight code fixes in the release, most eliminate processing delays or failures that occur when downstream partners process out-of-sequence change requests that modify the contents of the replication directory. Here's a summary of the key changes:

The update, which applies only to Win2K SP3 systems, contains new versions of four key FRS components: ntfrs.exe, ntfrsutl.exe, ntfrsapi.dll, and ntfrsprf.dll. The first two files have a release date of January 10, and the second two have a file release date of January 22, 2002. The documentation states that you can use two methods to install the update: Install the hotfix and reboot, or stop FRS, install the hotfix, and restart the FRS service. Given the sensitivity of these changes and the serious consequences that can occur because of a bug in the modified files, I encourage you to test it carefully before you deploy it in your production environment. This post-SP3 FRS fix is only available from Microsoft Product Support Services (PSS). For more information about the error messages that occur when FRS encounters any of the above situations, and for more details about other fixes, see the Microsoft articles "Improvements in the Post-Service Pack 3 Release of Ntfrs.exe" and "Issues That Are Fixed in the Post-Service Pack 3 Release of Ntfrs.exe".

First 2003 Security Hotfix
The first security hotfix of 2003 eliminates a buffer overflow condition that a malicious user can exploit to run code of the attacker's choice. The weakness exists in the native remote procedure call (RPC) Locator service (locator.exe) that's present in the server and workstation versions of Win2K and Windows NT 4.0 systems, and in both versions of Windows XP. Unless you change the system default, the Locator service starts automatically on Win2K and NT 4.0 domain controllers (DCs) but is set to manual startup on standalone server and workstation versions, as well as XP systems.

RPC communication is a core technique developers use to implement local and remote interprocess communication. When a system wants to communicate with a remote resource, the RPC service calls its locator service to translate a Universal Naming Convention (UNC) name into a network location. This name-lookup mechanism, also known as named pipes, uses the Server Message Block (SMB) protocol and TCP ports 139 (NetBIOS session port) and 445 (microsoft-ds or directory service port).

An attacker can leverage this exploit only on a system on which the RPC Locator service is running, which means DCs are vulnerable to both internally or externally launched exploits of this buffer overflow. On the workstation side, you can eliminate the problem by disabling the Locator service. However, any user with local Administrator privileges can easily enable the service, so this workaround isn't a permanent fix.

Microsoft Security Bulletin MS 03-001 (Unchecked Buffer in Locator Service Could Lead to Code Execution) documents the vulnerability and provides more information about the risk factors. The reference states that you can mitigate the risk of an external attempt to use this exploit by closing both TCP ports at the firewall. The bulletin gives the download locations for this hotfix, which is rated critical for DCs.