Microsoft Support Online article Q246045 documents a new Denial of Service (DoS) attack called RFPoison that disables a Windows NT client's access to shared-file resources and to other named-pipe connections. RFPoison sends a malformed packet that causes the server service to reference an invalid memory location and terminate with a Dr. Watson access violation "c0000005 in services.exe." After the Dr. Watson message appears, NT clients can't access shared-file resources or make other named-pipe connections to an NT-based server or workstation. Microsoft has a security fix called q246045.exe that closes this vulnerability; you can download it from the Microsoft Web Site.
Important Local Security Authority Hotfix
The LsaLookupSids() function returns the SID associated with a user or group account. In some cases, the function doesn't handle invalid or contradictory arguments correctly, which can corrupt the running copy of the Local Security Authority (LSA). LSA provides security services for Windows NT—it authenticates logon requests, verifies user privileges, determines whether users can gain access to resources, and oversees security auditing. This vulnerability essentially renders a system useless because the corrupted LSA service denies all requests for services.
When a user makes a service request that calls LsaLookupSids(), NT performs a security check to verify that the user has the required privileges before fulfilling the request. The vulnerability doesn't give anyone the capability to bypass the security check. However, the computer stops responding before making the check, so any user, regardless of privilege, can issue this call and cause the LSA to stop responding.
If you experience LSA corruption and your system hangs, reboot to load a clean, working copy of the LSA. Microsoft Support Online article Q248183 documents the vulnerability. It’s a gaping hole, and I recommend that you acquire and test the q248183.exe hotfix as soon as possible. You can download the Intel version or the Alpha version.
RRAS OSPF Doesn't Work
Microsoft Support Online article Q246860 states that RRAS doesn't select the optimum route to a network system or resource when you configure the server with Open Shortest Path First (OSPF). Until you obtain the bug fix—a new version of ospf.dll—you can work around the problem by disabling OSPF and entering static routes on your RRAS server. The article doesn't provide details about how or why RRAS calculates routes incorrectly, but it does state that the problem exists in all versions of RRAS, from Service Pack 1 (SP1) through SP6.
New Version of WLBS Available
Microsoft Support has an update for two Windows Load Balancing Service (WLBS) components, wlbs.sys and wlbs.exe. The update corrects unpredictable network connectivity problems that result from packet loss after a datagram exceeds a network’s Maximum Transmission Unit (MTU) size. The update also corrects a cosmetic problem: In the previous version, WLBS displayed the wrong value for data fields in the event log. You can read about these two fixes in Microsoft Support Online articles Q247817 and Q247819
Password Filter Update
The password filter function that accompanied Service Pack 2 (SP2) has a strong password policy stating that a password can't contain your username or any part of your full name. Microsoft Support Online article Q247975 documents a loophole in the policy that lets a user enter a password in the form "xxx*Userlastname123." If you're running the password filter, you should call Microsoft Support for a new version of passflt.dll that closes this loophole.
Windows NT Option Pack Downgrades MDAC Components
When you install the Windows NT Option Pack (Internet Information Server—IIS 4.0 and several other applications), the installation downgrades the existing Microsoft Data Access Components (MDAC) to the version that shipped with the option pack distribution media. This is a problem if you have updated MDAC components to the latest version for Y2K compatibility. To avoid overwriting newer versions, you need to comment out the line "DAC=dabsetup.dllo, DAGSetup, deagsetup.inf" in IIS installation file Iisv4.inf before you reinstall or reapply the option pack.
Microsoft Support Online article Q247553 documents the required .inf modifications and cautions that the workaround is effective only if your system already has MDAC components installed. If you disable the Option Pack MDAC installation on a system that doesn't have MDAC, IIS 4.0 won't run.
DNS and Firewall Interaction
When you use a Microsoft DNS server to resolve client queries for Internet hosts, the DNS server might not be able to resolve some domain names, including www.apple.com and www.fda.gov. This problem occurs when you use a Windows NT DNS server inside the firewall to query an authoritative name server outside the firewall, and the external DNS server that replies to the request has a different source IP address than the address you sent the query to. The firewall discards the reply from the external DNS server because the internal host (the DNS server inside the firewall) originally opened the connection to a different destination IP address than the IP address the reply was received on (the first external DNS server).
To avoid this problem, set the internal DNS "Forwarders" option to a DNS server outside the firewall. The forwarders option instructs the internal DNS server to do a recursive query to an external DNS server, which causes the reply to issue from the same source IP address that you sent the query to. Alternatively, you can set a rule on the firewall to allow any inbound traffic destined for port 53 to the IP address of the internal Microsoft DNS server. With this setting, the firewall won't drop the replies even though they're from a different source address than the one you sent the query to. Microsoft Support Online article Q247681 documents this name resolution issue.
DNS CNAME Translation
Most network administrators define multiple CNAME entries such as www and ftp on DNS servers to provide user-friendly names for internal Web sites. When the host record (the A record) resides in a delegated subzone, the DNS server responds incorrectly when you reference the CNAME as a fully qualified domain name (e.g., www.mynet.com). According to Microsoft Support Online article Q248123 , ping www.mynet.com and Nslookup www.mynet.com don't correctly translate the CNAME when the FQDN is defined in a subzone. The symptoms are
- The DNS server responds with "Bad IP Address" when you ping the CNAME.
- The DNS server responds with "Can’t find x.y.z: non-existent domain" when you use Nslookup to resolve the name.
To work around the problem, move the whole "zone records" section of the parent zone below the "delegated sub-zone" section in the DNS zone file. You can get a bug fix for this problem from Microsoft Support.
Looking for Winnt32.exe or Setupdd.sys?
The last couple of downloadable service packs haven't included the Windows NT native setup utility winnt32.exe or the SCSI driver setupdd.sys, although these files accompanied the service packs that shipped on CD-ROM. Winnt32 is a handy tool that lets you perform an upgrade or a reinstall on a running NT system and setupdd.sys recognizes your SCSI boot drive. According to Microsoft Support Online article Q236158 you can download these files from the NT Service Pack 4 (SP4) directory at the Microsoft FTP site. Even though you'll find the files in the SP4 directory, these two utilities operate correctly with SP4 through SP6a.