You might recall that Microsoft committed itself to releasing new service packs in a more timely manner. Windows NT 4.0 Service Pack 5 (SP5) appeared in May, leaving a gap of only 6 months between service pack releases (Microsoft released SP4 in November 1998). SP5 contains all the earlier service packs and hotfixes, so you don't need to have any prior fixes loaded—you can load SP5 to instantly update your NT 4.0 system.
According to Microsoft, SP5 doesn't add any new features to the OS, which explains why SP5 emerged so quickly after SP4. As of this writing, Microsoft admitted that the SP5 reference material was incomplete, but based on the initial documentation, this service pack corrects numerous known NT 4.0 bugs. Microsoft classifies these fixes into six categories: base operating system, Year 2000 (Y2K) issues, networking, shell, security, and other. You can find a list of each category's fixes at Microsoft's Web site at http://www.microsoft.com/ntserver/ nts/downloads/ recommended/sp5/updates.asp. This site also contains links to Microsoft articles.
What's New?
You can read about post-SP3 hotfixes and SP4 in "Hotfixes to Secure Systems," February 1999, and Mark Minasi, "Service Pack 4.0," March 1999. In this article, I concentrate on SP5 fixes that Microsoft released as post-SP4 hotfixes and discuss the new items in SP4 (that you can also find in SP5). To access a list of SP5's new features, go to the "Windows NT 4.0 Service Pack 5.0 Readme" file at http://www.microsoft.com/ ntserver/nts/ downloads/recommended/ sp5/readme.asp.
SP4 Hotfixes Bundled in SP5
Aside from the list of OS corrections, SP5 includes several post-SP4 hotfixes, which I'll discuss. For information about each hotfix and related Web sites, see the sidebar "Microsoft Articles."
For example, the update.inf file that Microsoft included in SP4 to fix the winprint.dll file contains the wrong pathname. SP5 corrects this problem. Be sure to read the Microsoft article "Windows NT 4.0 SP4 Setup Does Not Update Winprint.dll."
The Post-SP4 Roll-up fix contains seven hotfixes, which Microsoft rolled into one file to simplify installation. This fix contains TCPIP-Fix, Clik-Fix, SMS-Fix, MSV1-Fix, Infget-Fix, Nprpc-Fix, and Gina-Fix. The Microsoft article "WinNT 4.0 Post-Service Pack 4 Hotfixes Combined into One Package" contains details about this fix. The fixes and the eliminated problems include the following:
TCPIP-Fix. After you load SP4, the TCP/IP stack might not start up properly because of an initialization failure with 3Com's DynamicAccess driver. This incident occurs on multiprocessor systems, and the problem might also manifest itself with other network drivers. The Microsoft article "Intermediate Network Driver Causes STOP 0x0000001E on MP PC" contains the details.
Clik-Fix. SP4 incorrectly labels an Iomega Click 40! drive as a disk and assigns the device as B:\. Microsoft released a new driver to remedy this bug, as detailed in the Microsoft article "Windows NT 4.0 Does Not Recognize ATAPI Iomega Clik 40! Drive."
SMS-Fix. Severe memory leaks occur when the SNMP agent is under stress. This problem occurs because the agent fails to release a memory buffer. The Microsoft article "SNMP Agent Leaks Memory When Queried" details this problem.
MSV1-Fix. A logic error in SP4 lets users log on interactively with a blank password and connect to network shares. When users change their passwords via an NT or Windows 9x client, NT updates both the NT hash and LanManager hash forms of the password in the SAM database. However, when people use an older client (e.g., DOS, Windows 3.1, Windows for Workgroups—WFW, OS/2, or Macintosh) to change their password, NT stores the LanManager hash form of the password and stores the NT hash as a null value. When a user attempts an interactive logon or a network share connection from an NT system, the NT authentication process uses the NT hash form of the password. If the NT hash is null, NT uses the LanManager password hash for verification. The error in SP4 incorrectly lets the NT authentication process use a null NT hash value for authentication from NT systems. If users change their passwords from an older client, they can log on to that account from an NT system with a blank password. The Microsoft article "MSV1_0 Allows Network Connections for Specific Accounts" details the problem.
Infget-Fix. A malformed URL causes a Denial of Service (DoS) attack against the server by forcing the server to use all available memory. Internet Information Server (IIS) 3.0 or 4.0 stops responding or generates an access violation message when it runs out of memory. Refer to the Microsoft article "Specially-Malformed GET Requests Can Create Denial of Service" for details about this problem.
Nprpc-Fix. The Microsoft article "Denial of Service in Applications Using RPC over Named Pipes" describes a problem with NT's remote procedure call (RPC) service in which an attacker can launch a DoS attack against the spoolss.exe or lsass.exe files. The attacker uses named pipes connections to send random data. The RPC service attempts to close these connections and uses 100 percent of the CPU cycles, effectively creating a DoS condition by virtue of an unresponsive NT system.
Gina-Fix. An attacker who has physical access to the console of an NT system can retrieve the first line of text from a logged-on user's clipboard by pasting the clipboard contents into the username field of the Unlock Workstation dialog box. The Microsoft article "WinNT Lets You Paste Text into Unlock Workstation Dialog Box" includes details about the problem.
In addition to these fixes, the Microsoft article "RRAS Computer Stops Responding to Incoming Calls Under Stress" details another SP5 fix. A computer running RRAS might stop responding to incoming calls after a given amount of time. An insufficient buffer size in the kmddsp.tsp file causes this problem.
SP4 introduced a problem with Microsoft Exchange Server, in which SP4 causes the NDISWAN Services to return IP addresses in the order in which the OS binds them. The problem causes Exchange Server to fail to register Internet protocols that use unbound IP addresses, as explained in the Microsoft article "Exchange Protocols Fail After Applying Windows NT 4.0 SP4." This problem also might cause certain Winsock applications that use the GetHostByName API call, such as NetShow, to fail. The Microsoft articles "GetHostByName API Returns Unbindable Addresses" and "GetHostByName() Returns IP Address of Disabled Interface" describe this problem.
Security Updates
SP5 also includes a fix for a security risk in which the screen saver lets a user gain elevated privileges on the system. This problem arises when the Winlogon program performs a token change and NT doesn't verify that the change was successful. If a token-change failure occurs, NT reverts to operating under the security context of the built-in System account. Because of the lack of error checking, people can use a custom program to manipulate user settings to gain administrative control over NT. For more information about this problem, refer to the Microsoft article "Screen Saver Vulnerability Lets User Privileges Be Elevated."
In March, Microsoft announced a problem in NT 3.5 and later that lets users gain administrative privileges on the system they are interactively logged on to (SP5 corrects this problem). NT stores its core DLLs in virtual memory and shares the files with the programs running on the system, which helps avoid redundant copies of the DLLs in memory and improves memory usage and system performance. When a program calls a function that one of these DLLs provides, NT references the KnownDLLs list data structure (in the Registry) to determine the DLL's location in virtual memory. The NT security architecture protects in-memory DLLs against modification, but by default this architecture lets all users read from and write to the KnownDLLs list.
Users can modify the KnownDLLs list and load into memory a malicious DLL that has the same name as a system DLL, then change the entry in the KnownDLLs list to point to the malicious copy. NT will then direct programs that request the system DLL to the malicious copy. When a program with sufficiently high privileges calls this DLL, the DLL can take a malicious action (e.g., adding a user to the Local Administrators group). The Microsoft article "Restricting Changes to Base System Objects" explains how to protect against this problem by adjusting a Registry key setting.
Y2K
SP5's Y2K updates prevent problems in how the mfc40.dll file handles dates. For example, if the program passes the two-digit year date 99 to the DLL, mfc40.dll adds 1900 to make the date 1999, which presents a problem if the program passes a non-1900-based year date to the DLL. The problem manifests itself when you use a program such as msinfo32.exe. The Microsoft articles "Command Line Switches Supported by the Y2K Update" and "Mfc40.dll May Cause Programs to Display Wrong Date After 01/01/2000" describe this problem.
Worth the Effort
Microsoft has issued a host of OS corrections since the release of SP4. Although you should never load a new service pack without testing it, consider loading SP5—the fixes are worth the installation effort. For more ways to keep current, see the sidebar "Stay Informed."