An LPC Security Vulnerability

LPC Security Vulnerability
Last Thursday, Microsoft posted an alert about a security flaw called the Spoofed LPC Port Request Vulnerability. By design, one of the local procedure call (LPC) Ports API functions lets a server thread impersonate a client thread on the same machine. However, a loophole in the function’s validation process lets a malicious user with Logon Locally permission create threads and manipulate the impersonation request so that the thread runs in the context of another user, including the local System account. A malicious user can exploit this vulnerability to gain additional privileges on the local machine and create false audit records to cover the system exploit. If the domain administrator's credentials are on the local machine, this vulnerability can compromise security for the domain. Read more about the vulnerability at the Microsoft Web site. You can download the Intel security fix, q247869i.exe and the Alpha fix, q247869a.exe.

Redirector Network Performance
Microsoft made changes to the redirector (rdr.sys) in Windows NT 4.0 Service Pack 4 (SP4) that cause the redirector to generate unnecessary network traffic on systems running SP4 through SP6a. According to Microsoft Support Online article Q249799, the new redirector acts like its pre-SP4 predecessor. You can get the new version (which Microsoft released on December 23) by calling Microsoft Support. The article also documents a Registry entry users can create to toggle the redirector’s behavior between pre- and post-SP4 versions after you install the new redirector. (It’d be nice if we could skip the download and simply edit the Registry, wouldn’t it?)

You can find the redirector controls in the Registry path HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRdrParameters. Add the value entry FileSystemControlFilter:REG_DWORD to the Parameters key. To toggle the redirector, set the Registry value to 0 for pre-SP4 behavior, and set the value entry to 1 for post-SP4 behavior.

Domain Membership Change Requires Reboot in 10 Minutes
The Windows NT security model requires that all NT systems have a machine account (and an associated password) to log on to a domain. When you change a workstation or server’s domain, you must reboot the system within 10 minutes to ensure that the machine account password remains valid in the new domain. When the domain changes, the computer receives an account and synchronizes passwords with the PDC in the new domain. If you wait more than 10 minutes to reboot the system, you might see the message, "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on that account is incorrect. "

According to Microsoft Support Online article Q250877, the local Netlogon service runs a scavenger thread every 10 minutes that resets default machine account passwords. If you wait more than 10 minutes to reboot after you change domains, the Netlogon scavenger thread resets the machine account password using its active secure channel, which remains connected to the PDC where the system originally logged on. This scavenging replaces the machine account password from the new domain with the machine account password from the original domain. After you reboot, attempts to log on to the new domain fail because the computer account credentials are out of synch.

Windows Explorer ACL Problem
Microsoft Support Online Article Q250318 documents a funny interaction between Windows Explorer and the command-line utility Cacls. If you grant generic access permission using Cacls with the /G switch, Windows Explorer might display the message, "The parameter is incorrect" when you later attempt to view the folder’s permissions. Explorer’s ACL editor causes the problem because it doesn’t properly reset permissions when you specify GENERIC_ALL. You must call Microsoft Support directly to get the bug fix, which corrects the ACL editor problem. The article states that you can work around this problem by modifying ACLs with the Cacls /P switch, because when the switch replaces permissions, it removes any inherited permissions. The bug and bug fix apply to all versions of Windows NT 4.0, Service Pack 1 (SP1) through SP6a.

LPR Problems
Microsoft Support Online article Q250209 documents a technique you can use to diagnose and correct corrupted LPR port problems. Registry key HKEY_LOCAL_MACHINECurrentControlSetControlPrintPrintersprinter_name defines printers, and Registry key HKEY_LOCAL_MACHINECurrentControlSetControlPrintMonitorsLPRPorts defines LPR ports. Each LPR port should have an entry in the Registry, so if you know which port is causing the problem, you can delete the entry and restart the print spooler. If you’re not sure which port is causing a problem, you need to delete each port one at a time, stopping and starting the print spooler each time. When the remaining LPR ports reappear, you have successfully identified the bad one. In the worst case scenario, you might have to delete all the LPR ports from the Registry and redefine them in the Print Manager.

Print Spooler Hang
Microsoft Support Online article Q250038 provides a technique for clearing a print spooler hang. When you have a large number of print jobs (or a few very big print jobs) in the spooler folder, the spooler processes the queued jobs so slowly that the server acts like it is hung. To work around the problem, copy all the files from the spooler directory, which by default resides in WinntSystem32SpoolPrinter, to a temporary directory. Next, copy the files back a few at a time until all the jobs print. Of course, if large spool files prevent you from logging on, you’ll need to install another copy of Windows NT to access the spool files so you can move them—tedious, but effective!